This post is a long time coming. One of my duties as a PFE (Premier Field Engineer) is performing what we call an IIS Health Check, IISHC for short. This proactive service looks at the configuration of an IIS instance, the configuration and performance of the applications being served by that instance, the configuration and performance of the operating system (as it pertains to IIS) and the administrative policies around specific activities such as back-up and change control. With all of this information we compile a report that details our opinion as to the health of that instance.
I’ve done more of these health checks than I can remember but what I can remember is that there is a common theme among the areas where optimization is needed. In no particular order these areas are as follows:
PageFile configuration
The page file should be ~ 1.5x the amount of physical RAM (or the amount allocated to the VM) as a starting point and the initial and maximum values should be equal.
The reason for the size is primarily for kernel dumps. The OS will use the page file to dump out the contents of what’s in memory. If the page file is not large enough to dump out the full memory plus a bit for management, the resultant dump file will be truncated.
The reason for the initial and maximum values being equal is to combat against fragmentation in the page file. If the page file is less fragmented, paging performance will improve.
To determine the absolute best size for your page file, you should collect a good performance baseline and concentrate on what the paging counters are telling you. I’ll do another post about performance baselines soon.
More Info: RAM, Virtual Memory, Pagefile and all that stuff, How to determine the appropriate page file size for 64-bit versions of Windows
Thread Priority Optimization (Processor Scheduling) Setting
The Processor Scheduling setting should be set favor Background Services. Reason why? Most of the inner workings of IIS run as background services. Giving favor to Background Services basically gives IIS processor priority over foreground applications like desktop manager and the like.
More Info: HOW TO: Optimize Web Server Performance in Windows Server 2003
Anti-virus Real-time Scan Settings
If you have real-time scanning enabled, be sure to put exclusions in read and write scans for the following directories:
IIS Logs – Depending on how busy the sites are, lots of excessive writes going on here. Without this exclusion, every request will ultimately result in a scan unless you have logging disabled. I hope you don;t have logging disabled, that’s another post. The default is %SYSTEMROOT%/System32/logfiles/W3SVC##. IIS Compression Temp. Dir – If you have compression enabled, and I hope you do if your CPU(s) can handle it (another post), every compression run will result in a write scan. The default is “%WINDIR%\IIS Temporary Compressed Files. Temporary ASP.NET Files Dir. – If you have ASP.NET applications every page compilation could result in a write scan. Default is \%WINDIR%\Microsoft.NET\Framework\vYOURVERSION(S)\Temporary ASP.NET Files.
IIS Logs – Depending on how busy the sites are, lots of excessive writes going on here. Without this exclusion, every request will ultimately result in a scan unless you have logging disabled. I hope you don;t have logging disabled, that’s another post. The default is %SYSTEMROOT%/System32/logfiles/W3SVC##.
IIS Compression Temp. Dir – If you have compression enabled, and I hope you do if your CPU(s) can handle it (another post), every compression run will result in a write scan. The default is “%WINDIR%\IIS Temporary Compressed Files.
Temporary ASP.NET Files Dir. – If you have ASP.NET applications every page compilation could result in a write scan. Default is \%WINDIR%\Microsoft.NET\Framework\vYOURVERSION(S)\Temporary ASP.NET Files.
All Content Dirs – Unless a request is being served from in memory cache, every request to will result in a read off the disk which will trigger a read scan.
More Info: A 0-byte file may be returned when compression is enabled on a server that is running IIS,
Explicitly Backing-up the Metabase
before changes are propagated to IIS, it’s a good idea to get an explicit backup of the metabase. This way if there’s a mishap with the change, it is easy to rollback.
Many administrators rely on system state backup for this. It is true that system state will grab a copy of the metabase however, it also includes registry, COM+ database, etc. That’s allot to re-deploy if all your after is an IIS change. Instead use IISBACK.vbs or the like.
More Info: Backing Up IIS Configurations Using Iisback.vbs (IIS 6.0)
These are probably the top offenders. There are a whole lot more but, I have to give you a reason to come back right? In the next post, I’ll get down a bit deeper. Stay tuned.