This evening I was asked whether I would recommand disabling IIS log file to make sure the SMP console runs as fast as possible.
My answer was (and remains) a big NO. Do _not_ disable IIS logging. It contains a lot of good information on it (that I am a big consumer of, but the value is there to anyone).
So, first lets dispell this nonsense about improving performances.
IIS logging is done on the http.sys driver, so it run in the Windows Kernel. You can verify this using procexp as per the image below. This means logging requests once they are completed (as this is when it) does not cost any context switching (as it would if it was in living user space). Besides, each entry is normal less than 1024 bytes, which means the "cost" of logging entries is fractional: push the information already held in memory to disk.
If you compare the cost of doing this tiny little task with what happens in user mode in the w3wp.exe (handling the request in ISAPI first, then going thru the .Net System.Web.HttpRuntime, System.Web.HttpApplication- before the Altiris.NS code is loaded, this is even less than fractional - it's anecdotal.
But it doesn't mean it should be left as-is ;). Here are a few recommendations I usually make to my customers:
- Move the log files outside of the system drive
- Configure the logging to rollover daily (not hourly)
- Un-select the CS-UserAgent field as it can be long and is unecessary
Oh, and remember to check them regularly - it'll show you at a glance usage pattern changes and problems in the environment (if the size doubles from one day to the next for example, or if it reaches improbable Gigabyte size as is the case with my customer).