Это - хорошая практика для использования Сжатия NTFS на папках IIS Log?
После многих часов findling. Мои ГРУШЕВЫЕ ключи указывали на php 5 вместо php 5.2, который является php версией, которая находится в моем пути.
Как сказано выше, перечислите грушевые ключи с
$ pear config-show
И затем установленный ключи
pear config-set [key] [path]
PEAR documentation directory doc_dir /Applications/MAMP/bin/php5.x/lib/php/doc
PHP extension directory ext_dir /Applications/MAMP/bin/php5.x/lib/php/extensions
PEAR directory php_dir /Applications/MAMP/bin/php5.x/lib/php/PEAR
PHP CLI/CGI binary php_bin /Applications/MAMP/bin/php5.x/bin/php
php.ini location php_ini /Applications/MAMP/conf/php5.x/php.ini
Signature Key Directory sig_keydir /Applications/MAMP/conf/php5.x/pearkeys
Удостоверяясь, что 5.x php версия, которую Вы используете. Узнать, какова Ваша php версия
$ php -i
Теперь, если я могу только заставить php модульный тест устанавливать * вздох *
As Evan already gave a general answer, I like to address two of your sub-questions:
Does IIS flushes logs every X minutes?
http.sys, the kernel mode part of IIS is responsible for logging and it buffers the data in memory before writing it to the log files. I'm not certain but I don't think it does the flushing every x seconds, more likely after its buffer is getting full.
Does the whole file need to be read when adding a single line?
No, NTFS writes updates to a file into its own cache and then compresses and appends the data asynchronously to the file. Writing to a compressed file is not significantly slower than to an uncompressed file.
So there should be no problem with using NTFS compression on IIS log files.
Sources:
IIS 7 Resource Kit, Chapter 15:Logging - Microsoft Press 2008
Windows Internals 6th Edition Part2, Chapter 12: File Systems Microsoft Press 2012
I compress my IIS logs on a lot of IIS servers, albeit mainly servers that are hosting Outlook Web Access/App or low volume web sites. I have no problems doing it, and quite like the disk space savings.
In general, you're trading CPU for storage by making this decision. If you're CPU-bound to begin with then this probably isn't a good tradeoff. For my OWA servers, which can grow gigabytes of logs a day (thanks ActiveSync devices) I think the tradeoff is a good one.
The NTFS filesystem driver handles the compression, so it doesn't change how IIS writes to the files.
Edit:
You are, potentially, also trading-off some I/O bandwidth and IOPS, too. If you're a high enough volume that your log writes are a significant consumption of I/O resources you could see a decline in I/O consumption from enabling compression, too.
The only way you're going to tell how this impacts you is to benchmark it yourself. Take a baseline with compression disabled and then enabled and compare them. There's no magic wand to wave to know how it will impact you-- there's just too many non-deterministic factors in play.