Planning, testing and tuning for ASP.NET and IIS 6.0






4.71/5 (24 votes)
Nov 18, 2004
19 min read

126072
An approach to proactive IIS 6.0 server management and ASP.NET performance tuning and testing. We will look at editing the Metabase for expanding the use of GZip, at threading, at compression, at security, IIS 6.0 object cache, and a host of other topics.
So let us take advantage of performance testing/tuning
and then alter some settings for Windows 2003/IIS 6.0.
Unfortunately where to start a testing and tuning process can be driven by who has the biggest issues first. Would it be the Server Admin, the Architect, the Developer, or the user who experiences a slow-down? If there is a large out-cry from users, or you expect traffic to rapidly expand with a new roll-out, you may not want to be caught off guard by not being proactive. Possibly all of you may want to go through some ASP.NET Performance Checklists with your staff: A short list of topics from the above link include:
| ||||||||||||||||||||
Of course you are going to need a "MS Web Application Stress Tool" for some testing: http://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx Then you can begin to chart out and then tune your .NET applications performance: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt16.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt17.asp | ||||||||||||||||||||
Then you can begin to take this information and compare it against the many ASP.NET How To documents: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto.asp Topics include:
See also http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx |
1) So let's try some things out and retest after implementation.
GZip - IIS 6.0: While the benefit will be for Firefox and IE 6.0 browser users for now it is worth your attention. Do note though that Gzip gains are in bandwidth and as gains in "perceived" speed of page loads. It could also help reduce the amount of bytes sent by the server, so for high volume servers this could yield more sizable results. Also note CPU utilization spikes may result. For more details see: Check your Scalability and work with GZip Headers: The original specs for GZip are also sometimes useful: |
Edit the MetabaseWARNING: If you edit the metabase incorrectly, you can cause serious problems that may require you to reinstall any product that uses the metabase. Microsoft cannot guarantee that problems that result if you incorrectly edit the metabase can be solved. Edit the metabase at your own risk. NOTE: Always back up the metabase before you edit it. See http://support.microsoft.com/?id=322603 for more information and for other issues to help you mitigate issues. |
Then see http://www.dotnetdevs.com/articles/IIS6compression.aspx by Brad Wilson for further instructions and a decent trace tool.
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/qos_utilbandwdth.asp |
2) Caching, Threads, and SSL- They gave you more in IIS 6.0 so why not use it and tweak it? (Some of the "Highlights".)
"Windows Server 2003 and IIS 6.0 provide kernel caching. ASP.NET pages can automatically benefit from the IIS 6.0 kernel cache. Kernel caching produces significant performance gains because requests for cached responses are served without switching to user mode." 3
Trim Your Page's "K" size to regain bandwidthProcessing large page sizes increases the load on the CPU, increases the consumption of network bandwidth, and increases the response times for clients. Avoid designing and developing large pages that accomplish multiple tasks, particularly where only a few tasks are normally executed for each request. Where possible logically partition your pages. To trim your page size, you can do one or all of the following:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp -- other optimizations are contained within. | |||||||||||||||||||||
Retime the IIS Object Cache 4Consider shortening the period of time that an unused object remains in the cache, or lengthening the time that a used object remains in the cache, by adding the ObjectCacheTTL entry to the registry. CautionDo not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Windows Server 2003 Resource Kit companion CD or on the Web at http://www.microsoft.com/reskit. ImportantYou must be a member of the Administrators group on the local computer to run scripts and executables, or you must have been delegated the appropriate authority. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile /User:MyMachine\Administrator cmd to open a command window with administrator rights and then type cscript.exe ScriptName (including the full path with parameters, if any). To reset the period that unused objects remain in the cache 4
Change the Balance of the File System Cache to the IIS 6.0 Working Set By default, servers running Windows Server 2003 are configured to give preference to the file system cache over the working sets of processes when allocating memory (through the server property Maximize data throughput for file sharing). Although IIS 6.0–based servers benefit from a large file system cache, giving the file system cache preference often causes the IIS 6.0 pageable code to be written to disk, which results in lengthy processing delays. To avoid these processing delays, set server properties to maximize data throughput for network applications. To maximize data throughput on the server for network applications 4
Limit Connections If your server does not have enough memory, limiting the number of connections on the server might help alleviate the shortage because some physical memory (about 10 KB per connection) is consumed by the data structures that the system uses to keep track of connections. For more information about limiting connections to save memory, see “Limiting Connections to Manage Resources” earlier in this chapter. If you are running your server in worker process isolation mode, you can limit application pool queue lengths to prevent large numbers of requests from queuing up and overloading your server. When the queue length limits feature is enabled (it is enabled by default), IIS monitors the number of requests in a designated application pool queue before queuing a new request. Use IIS Manager to change the default limit of 1,000 requests for application pool request queues. If adding a new request to the queue exceeds the maximum queue length, the server rejects the request and sends a 503 error (Server Too Busy) to the client. However, requests that are already queued remain queued even if the limit is changed to a value that is less than the current queue length. Use the following procedure to set a limit on the queue length for an application pool. 4Important
For information about configuring application pool queue length limits by using metabase properties, see the AppPoolQueueLength property in the “Metabase Property Reference” in IIS 6.0 Help. Adjust Resource Allocation in Windows 4System processing is managed by Windows Server 2003, which can allocate processor and memory resources among tasks. If your server needs a temporary performance boost, you can temporarily adjust resource allocation in Windows to allocate the resources where you need them: For more information about changing the way that Windows allocates processor resources, see “Change the performance of foreground and background programs” in Help and Support Center for Windows Server 2003. Always keep in mind that performance logging uses system resources. When you are not actively checking performance, disable performance-related logging to squeeze a bit more performance from your server. 4 Configuring ServerCacheTime for SSL Sessions 4If you plan to support long SSL sessions, consider lengthening the SSL cache time-out interval by adding the ServerCacheTime entry to the registry. If you expect thousands of users to connect to your site by using SSL, estimate how long you expect SSL sessions to last, and then set the value of the ServerCacheTime entry to a number slightly higher than your estimate. Do not set the value much higher than your estimate, because the resulting time-out interval might cause your server to retain stale data in the cache.
to open a command window with administrator rights and then type
To configure the ServerCacheTime registry entry 4
http://download.microsoft.com/download/7/4/f/74fe970d-4a7d-4034-9f5d-02572567e7f7/19_CHAPTER_6_Optimizing_IIS_6.0_Performance.doc <<<----- The full book is located at: http://www.microsoft.com/downloads/details.aspx?FamilyID=80a1b6e6-829e-49b7-8c02-333d9c148e69&DisplayLang=en#filelist and will provide your Server Admin and those concerned with managed code with a lot of great "bed-side reading". ;-I |
By now you should have a good list of things to consider, code to implement, settings to change, and a lot more knowledge base to make proactive decisions from.