IIS 6 Performance Tuning Ideas


 

IIS 6.0 performance tweak guide (draft) from http://forums.iis.net/t/1148571.aspx

Standard Resource Toolkits on the servers

The basic installation of IIS doesn’t come with many useful tools for administration.

Consider installing the following additional software that should be installed on all web servers:

 Microsoft IIS Resource Kit

 Microsoft IIS Diagnostic Toolkit (and download the latest versions of the apps that come with these kits e.g. DebugDiag, LogParser)

 Microsoft Sysinternal Suite (stuff like process explorer, etc) http://technet.microsoft.com/en-gb/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx

 Microsoft Network Monitor (latest version)

 A better text editor than standard notepad like notepad++

Standardise the build of the servers so they are basically the same.

Hosts


It is useful to be able to access the sites on your server from the server. This is useful for many reasons detailed error messages, traffic flow through the infrastructure so you know you are on the correct machine, etc.

Many production environments there may be firewalls and policies in place to stop you doing this if possible you should try and obtain this.

It may be as simple as trusting your own sites in Internet Explorer so they are allowed through hard admin

Often in farm environments it is useful to know the actual server that they you are on.

You could have many servers and the hardware load balancer that controls what traffic comes to which server sometimes isn’t helpful.

In this case it may be may be useful set up additional host headers and host files references on the production servers in the farms so you can directly access that specific server from its browser. 

Make sure all the web farms files are in synch

Nightly checks of the webfarm files to make sure they are all in synch with each other.

We can script this for all the files or schedule tasks with a package like windiff to ensure they are all in synch. Send out mail alerts if they are found to be out of synch.

Additionally we can modify this so we can work out if staging is in synch with the production server farm. Obviously there will be some changes between the web configuration files but it is still a useful maintenance technique.

Also check these with the disaster recovery servers to ensure they are all in synch.

Checking the details of each websites config files (e.g. web.config, etc) and each server metabase file of the farm is also very useful. Obviously these things shouldn’t change but it would be useful to know if they did.

Luckily, Microsoft are in the process of writing an app for this and other purposes.

Web Deployment Tool (currently in a useable tech preview stage) has been designed for IIS7 and for migration from IIS6. But it also features a useful looking comparison tool to compare the states of multiple IIS6 servers.

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1602

Application Pool Recycling

By default an application pool has a recycle period of 1740 minutes or 29 hours. This is a ludicrous setting as it will be recycling application pools in peak times.

Much better is to recycle the application pools at fixed off peak times. For example - 1:00am.

For servers in farm environments stagger these recycle times so they are not all the same. E.g. Server A – 1:00am, Server B – 1:10am, Server C – 1:20am, etc

Additionally you can log when the app pools recycle. There are many reasons for a recycle and by default these are not recorded in the event viewer (very little is recorded by default for us admins). It is useful to have this for all events that occur.

Complete list:

AppPoolRecycleTime
AppPoolRecycleRequests
AppPoolRecycleSchedule
AppPoolRecycleMemory
AppPoolRecycleIsapiUnhealthy
AppPoolRecycleOnDemand
AppPoolRecycleConfigChange
AppPoolRecyclePrivateMemory

To turn them all on:

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

HTTP Compression

This can be especially useful for static web content as the compression only has to be done the once and then cached. Dynamic content is compressed on the fly and not cached.

One of the main areas of usefulness of compression is the saving of the network traffic and thus a potential reduction for your hosting bills.

Although HTTP compression was previously more useful where there was less broadband and more dialup in years gone by. In today modern environment it is still a useful tool and should not overlooked. Increasingly people are also using mobile, wireless, etc in greater numbers and these will benefit much more with compression.

One of the previous downsides to HTTP compression years ago was that browsers did not support the HTTP 1.1 standards for this but from, I think IE5.5, they have been setting this ‘on’ as default.

(The benefits of an Intranet environment is that, in general, you have fewer multiple browsers to be concerned about as you are likely to know what company standard browsers are.)

Obviously static previously uncompressed content like HTML pages can benefit a lot from compression.

Although on an intranet the rewards of compression of web content should more than make up for small CPU overhead of producing the compression in the first place.

The server is not local and is in Ireland so people connecting to the UK intranet will benefit from the reduced amount of traffic. For quickly produced pages on the website the main area of slowdown for the user will the time it take to receive the pages across the network.

For the infrastructure here you will probably be saving 30% in network traffic overall (plain text files; HTML, ASP, JS, etc (we can configure in the metabase what files we want to compress beyond the default ones) will benefit from 50-60% size reductions for compression, jpegs, and other already compressed formats do not get compressed by default or do we want the extra processing power of compressing them) for a small increase in CPU time which still shouldn’t be more than double the current CPU load (which is very low nearly always below 5%) even maxed out.

Here is some sample data from Microsoft on the issue:

Blah blah blah

Default Documents order

This is a little anal but it is sadly a common occurrence. Place the actual ‘default content page’ of the website at the top of the list.

For example if you default page is

www.mywebsite.com/default.asp

then don’t have a default documents order of

Default.aspx
Default.htm
Default.asp
Index.htm

I know I am being a little anal as this is a small overhead in IIS where it looks first for the other files. As this happens every time, people could be going to them tens of thousands of times a day and it would (slowly) add up.

Now I don’t know if here all pages are referenced directly with full URLs in which case this is less relevant but still best practice and worthwhile implementing.


More detailed logging

 By default and IIS site only has the standard default IIS logging turned on.

There are many more useful fields that we turn on and although these make the logs bigger can but very useful when you can query search through them. Often cookies is not need and is a large

True you can save some CPU time if you reduce what you log (especially with things like useragent) but the usefulness of these logs more than outweighs the benefit.

However to get this really useful you have to search it.

The LogParser tool is very useful however I would recommend going one step further and collating them if possible in a database.

This give you more scope and makes it very easy to troubleshoot.

(Although this is more useful as the types of problems are different in a large Internet environment rather than an Intranet one it is still very useful.)

Some example scenarios that it would have been really handy in the brief time I have been on the servers.

Troubleshooting a problem where we are investigating an unresponsive IIS server.

Often a sign of the impending problems might be in the logs might be a collection of 500 errors and failure can happen

To find out when the errors first occurred we can write queries on the log database for all servers in a particular farm.

We can narrow the searches down easily to a particular directory, server(s), refers, user, headers, http status codes (and in IIS 6 error sub-codes), etc.

Then we can see patterns in the 500 errors to see what occurred there.

This process is very difficult to do at present with flat logs when you are looking over days across a farm of multiple server and if you have to search large files over multiple parameters it nearly impossible.

There are very few tools for troubleshooting IIS web server problems and many of these have to run in real-time before the error occurs which is never ideal on a production machine (and we have to wait for the error to occur again)

So collating the IIS logs into a searchable form is a very useful tool.

Optimising connection timeouts

The default setting for a site is that a connection stays open for 120 seconds of inactivity before closing and the visitor will have a establish a new connection.

This is controlled on a per-site basis.

Website properties  Website tab.

Http Keep-Alives and connection timeout.

We are using the best practice of Keep-Alives how the time out period is that of the default. This is generally regarded as being too high. We should reduce this to 60 seconds (or less – many recommend 30 seconds) which is more realistic.

Caching

Optimising object cache TTL (time to live)

By default IIS hold every object in a cache for 30 seconds then it is discarded.

For a dynamic environment, like webappfarm, this is really not needed so the recommend best practice is that this can be reduced. I would say to 10 seconds.

Conversely for servers which hold a lot of static connect (the rest) it is recommended that this time is increased. I would say about 60 seconds some say longer.

This is control via the registry only and is sever wide.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters

Create ObjectCacheTTL as a Dword and assign the value (in seconds)

More Caching

IIS cache size is, by default, half the physical memory in the box (metabase reg - MemCacheValue). However there is a limit of the maximum size of each file held in the cache (metabase reg – MaxCachedFileSize) this by default is set to 256KB.

It is worth carefully checking the environment for commonly referenced files to see if any are over the 256KB default maximum. If we have a commonly accessed file that is over the limit then it makes sense to increase this limit.

Look out for large pictures on common pages and increasing rich media like flash and video clips.

Caching ASP content

aspScriptFileCacheSize is the amount of asp pages that by default this is 500. Heavy usage server with a lot of asp content could benefit from an increase in this value however there are various counters to monitor before we need to change the value (and other related values, asp cache to disk, etc). Here Microsoft explains:

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a9171159-c801-4705-b8a9-9eecf58a892f.mspx?mfr=true


Working set preferences

By default windows 2003 gives priority to the file system cache rather than the programs or working set.

It is generally recommended that you change to the working set (programs) rather than the file system.

This is common practice and highly recommend in say, an SQL Server environment, which have even more control of the memory resources in the program. IIS does benefit from this to a less degree hence why they do not turn it on as default as in SQL Server.

System Properties  Advanced tab  Performance  Advanced Tab  Memory Usage  Adjust performance for Program.

Additionally going hand-in-hand with this is changing the preferences of the network card to optimise file and print sharing for the network application data.

Initially, I thought, that as IIS serves files than a large system cache is needed. However IIS is a network file and application server not strictly a file server or an application server and therefore has more of a benefit for network priority.

Network Connections  Local Area Connection (for each connection)  Properties  File and Printer Sharing  Properties  Optimization  Maximize data throughput for network applications. – instead of file sharing which is default 2003 server setting (again SQL server machines will change the default to network apps)

Configure more detailed reporting in performance monitor

Configure Performance monitor to display associated process IDs instead of the incremental numbers (e.g. w3wp_5432 (where PID = 5432) instead of w3wp#1, etc) more details 
http://support.microsoft.com/kb/281884

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance\

Create ProcessNameFormat as a Dword and assign the value 2

Configure the admin user settings

Although a personal preference, there are useful features that you can enable/disable for admin of an IIS server.

These include:

Turning off ‘Show Friendly HTTP messages’ in IE

Create a dedicated web admin config msc file for mmc – include iis, computer management, com, .net components and all things that you need.

In task manager turn on more columns 
Most useful are: 
ProcessID counter (so we can work out the name (with iisapp.vbs) of what worker process app pools are taking up the most resources) [this was turned off by default in Win2003]

Virtual Memory

Trivial this but I have always used 1.5 times (or more) the memory for virtual memory. Most of the IIS best practice document I have seen seems to indict this. I believe 1.5 times is the recommend windows amount for any windows server.

 

Original Article: http://www.tech-faq.com/iis-performance-monitoring-and-tuning.shtml
  • System Monitor: The System Monitor is the one of the main MMC snap-ins used to monitor system performance. This was previously the Performance Monitor tool in Windows NT. The name change to System Monitor occurred in Windows 2000. Through System Monitor, you can monitor various elements of the performance of a server, and you can collect and view real-time data or you can view historically collected data. System Monitor can be displayed in a graph, histogram, or report format. System Monitor uses objects, counters and instances to monitor the system. An object can be described as a collection of counters that is associated with a system resource or service which produce the data you can assess. When an object executes a function, its associated counters are updated. A counter can be regarded as a data reporting component in an object. The counter represents data for a particular component of the system or service. An instance refers to the incident of multiple performance objects of the identical type on a computer. An object can have one or multiple instances.

You have to be a member of one of the following groups to use System Monitor:

  •  
    • Administrators
    • Server Operators
    • Performance Monitor Users
    • Performance Log Users

To open System Monitor,

  •  
    • Click Start, Run, enter perfmon.exe in the Run box, and click OK.
    • Click Start, Administrative Tools, Performance, and then click System Monitor.

A few of commonly monitored objects include,

  •  
    • Processor
    • Memory
    • Logical Disk
    • Physical Disk
    • DNS
    • DHCP Server
    • Network interface
    • Web service

To add counters in System Monitor,

  •  
    • Open System Monitor
    • Click Add to open the Add Counters dialog box.
    • You can choose the Use Local Computer Counters option to monitor the local computer, or you can choose the Select From Computer option.
    • When you use the latter option, you can select a computer from the list and choose counters for that particular computer.
    • Choose the performance object from the list.
    • You can click the All Counters option to monitor all counters associated with the object, or you can click the Select Counters From List option to individually select counters.
    • Click the All Instances option to track all instances, or alternatively click the Select Instances From List option to individually select instances.
    • Click the Add button to add the counters.
  • Performance Logs and Alerts: You can create counter logs and trace logs, and configure alerts by using Performance Logs and Alerts. Any created logs can be viewed through System Monitor, or exported to a database or spreadsheet. Because performance logging runs as a service, a user does not need to be logged on to the computer being monitored to collect data. You can view data while it is being collected, or after the data has been collected. You can define an alert for a counter to initiate an action when the counter value surpasses or drops below a predefined setting. Counter logs are used to record system performance data at specified intervals. Trace logs are used to record comprehensive system events after the particular event occurred.

To access Performance Logs and Alerts,

  •  
    • Click Start, Administrative Tools, Performance, and then expand Performance Logs And Alerts.
  • Task Manager: If you want to view all applications and processes running on a Windows Server 2003 computer, and view a few common performance measures, you should use Task Manager. You can Task Manager to view system activities such as active applications and processes, memory and CPU usage of processes, and the users who are currently logged on to the server. You can also view a number of memory and network usage statistical information.

To open Task Manager, use of the methods listed below:

  •  
    • Click Start, Run, enter taskmgr.exe in the Run box, and click OK.
    • Press Ctrl + Alt + Delete and select the Task Manager button.
    • Right-click an empty section of the taskbar, and then click Task Manager.
  • Network Monitor: You can use Network Monitor to monitor network traffic, and to troubleshoot network issues or problems. You can also use Network Monitor to gather network information that can be used in capacity planning efforts, and to establish baselines. Network Monitor shipped with Windows Server 2003 allow you to monitor network activity and use the gathered information to manage and optimize traffic, identify unnecessary protocols, and to detect problems with network applications and services. In order to capture frames, you have to install the Network Monitor application and the Network Monitor driver on the server where you are going to run Network Monitor. Network Monitor saves captured data to a temporary capture file that you then save with a .CAP extension. This enables captured data to be examined in Network Monitor. You can design a capture filter to capture only specific frames, or you can configure it to respond to a specific condition.

To install the Network Monitor Driver :

  1.  
    1. Open the Network Connections folder
    2. Right-click Local Area Connection, and select Properties
    3. When the Properties dialog box is displayed, click the Install button.
    4. When the Select Network Component Type dialog box is displayed, click Protocol in the Component list, and click the Add button
    5. When the Select Network Protocol dialog box is displayed, click Network Monitor Driver.
    6. Click OK.

To install the Network Monitor application

  1.  
    1. Click Start, click Control Panel, and click Add or Remove Programs
    2. When the Add Or Remove Programs dialog box is displayed, click Add/Remove Windows Components
    3. This initiates the Windows Component Wizard
    4. Select Management and Monitoring Tool, and click the Details button
    5. Select the Network Monitor Tools check box, and click OK
    6. Click Next and Click Finish
  • Web Application Stress Tool (WAST): You can use WAST to simulate the following:
    • Simulate the effect of multiple web browsers concurrently connecting to IIS to run applications
    • Simulate the effect of multiple web browsers concurrently connecting to IIS to download Web content
    • Simulate different loads so that you can determine the effect on the Web server.

When monitoring Windows Server 2003 and IIS, it is recommended to monitor counters for the following system resources, or objects:

  • Memory
  • Processor
  • Disk
  • Network

The performance counters that you should enable for the above system resources to monitor IIS performance are listed below.

  • Memory: The counters useful for IIS monitoring are:
    • Available Bytes, maintain over 20MB.
    • Cache Bytes, a decrease could be indicative of IIS memory depleting
    • Committed Bytes, maintain beneath 75 percent of physical memory.
    • Page Faults/sec, consider adding additional RAM when hard page faults are degrading IIS performance.
    • Pages/sec, maintain a low figure. You should consider supplementing RAM when the counter is over 80.
    • Pool Nonpaged Bytes, if the counter gradually increases, verify that none of your applications have memory leaks.
  • Processor: The counters useful for IIS monitoring are:
    • % Processor Time, a processor bottleneck typically exists when this counter is over 80 for a continued time, and network usage is low.
  • Disk: The counters useful for IIS monitoring are:
    • % Disk Time, it is recommended to maintain a low value for this counter.
    • Avg. Disk Bytes/Transfer, it is recommended to maintain a high value for this counter.
    • Avg. Disk Queue Length, it is recommended to have a value of 4 or lower.
  • Network: The counter useful for IIS monitoring are:
    • Bytes Total/sec, the value should be checked to the bandwidth of the network card to determine if any network connection bottlenecks exist.

The performance counters of the WWW Service objects that you should enable to monitor the WWW service are listed below.

  • WWW Service: The counters useful for IIS monitoring are:
    • Bytes Total/sec, the counter value should be high
    • File Cache Hits, for static content, the counter value should be quite high.
    • File Cache %, a low counter value could possibly mean that you have to re-examine the design of your applications.
    • ISAPI Extension, a drop of this counter during heavy load could mean that your application might be a bottleneck.

The performance counters of the Active Server Pages object that you should enable to monitor ASP are listed below.

  • Active Server Pages: The counters useful for IIS monitoring are:
    • Requests/Sec, a drop of this counter during heavy load could mean that your applications might be a bottleneck.
    • Request Queued, maintain a low counter value
    • Request Wait Time, the counter value should generally be low.

Tuning IIS for Maximum Performance

One definite way to ensure maximum IIS performance and security is to have your servers running in the worker process isolation mode of IIS 6. This is the default application mode in IIS 6, where all the new architectural features of IIS 6 are enabled, including:

  • Application pools and worker processes provide the following key features:
    • CPU monitoring, Processor affinity, Health monitoring, Rapid-fail protection, Recycling, Startup and shutdown time limits, Queue length limits, and Idle timeout capabilities.
  • ASP.NET provide the following features for applications:
    • Improved performance over ASP applications, extensive programming language support, and XML integration.

To switch to worker process isolation mode,

  1. Open the IIS Manager
  2. Right-click the Web Sites node, and click Properties from the shortcut menu.
  3. When the Web Site Properties dialog box opens, click the Services tab.
  4. If you want to use worker process isolation mode, clear the Run WWW service in IIS 5 isolation mode checkbox.
  5. Click OK.
  6. Restart IIS

How to tune application pools through recycling

Recycling a worker process improves the reliability of IIS. Recycling is beneficial for faulty Web applications which are typically caused by memory leaks. Through recycling, you enable IIS to periodically restart worker processes which are currently servicing an application pool. You can configure recycling for a worker process using a number of criteria:

  • Once a predetermined number of minutes of inactivity have passed: The default setting is 1740 minutes.
  • Once a worker process has serviced a predefined number of requests. The default setting is 35,000 connections.
  • After the virtual memory usage by the worker process attains a specific threshold.
  • At a specific time of the day

To manually recycle a worker process,

  1. Open IIS Manager
  2. Locate and right-click the application pool associated with the worker process, and select Recycle from the shortcut menu.

To configure all worker processes in each application pool to recycle according to the same criteria,

  1. Open IIS Manager
  2. Right-click the Application Pool node in the console tree, and select Properties from the shortcut menu.
  3. The Recycling tab is utilized for configuring recycling.

How to configure the idle timeout feature for all application pools

Through the idle timeout feature, you can enhance web server performance by enabling IIS to shut down idle worker processes. Enabling the idle timeout feature assists in eliminating system resource wasting that normally occurs when worker processes run idly. It allows you to better manage system resources, preserve resources so that they are available when needed, and free up resources.

To enable the idle time feature,

  1. Open IIS Manager
  2. Right-click the Application Pool node in the console tree, and select Properties from the shortcut menu.
  3. Click the Performance tab.
  4. In the Idle Timeout area of the Performance tab, enable the available checkbox and specify the inactivity time duration after which the worker process should shut down. The default setting is 20 minutes.
  5. Click OK.

How to enable the Request Queue Limits, CPU Monitoring, and Web Gardens features to improve IIS performance

  • A lengthy request queue can result in clients considering the performance of the IIS server as being slow. To prevent this from happening, you can limit the request queue for applications in an application pool. This feature is configured on the Performance tab of the Application Pool’s Properties window.
  • You can enable CPU monitoring to track the usage of CPU by the worker processes of an application pool. You can also configure IIS to shut down the worker processes of the application pool when their CPU usage has exceeded a specified threshold. This feature is also configured on the Performance tab of the Application Pool’s Properties window.
  • Web Gardens, another IIS feature, improves IIS performance by allowing multiple worker processes to service one application pool. When a worker process fails, the remainder of the worker processes continue to service the application pool.

To configure the Request Queue Limit, CPU Monitoring, and Web Garden features,

  1. Open IIS Manager
  2. Right-click the Application Pool node in the console tree, and select Properties from the shortcut menu.
  3. Click the Performance tab.
  4. Enable the checkbox under the Request Queue Limit section of the Performance tab, and set the appropriate limit.
  5. Enable the checkbox under the CPU Monitoring section of the Performance tab, and specify the fitting setting value. Specify the action that IIS should take when the specified CPU usage level is exceeded.
  6. Enable the Web Garden feature by selecting a value greater than one in the Web Gardens area of the Performance tab. A value of one indicates that the Web Garden feature is disabled.
  7. Click OK.

How to configure Health Monitoring features

  • You can enable health monitoring for worker processes to determine whether they are functioning correctly. Health monitoring is enabled by selecting the Enable Pinging checkbox on the Health tab of the Application Pool’s Properties window.
  • Rapid-fail protection is another IIS feature that enables you to detect when multiple worker processes associated with an application pool are performing incorrectly. You enable rapid-fail protection by selecting the Enable Rapid-Fail Protection checkbox on the Health tab of the Application Pool’s Properties window. To configure the feature, you would need to specify how many worker process failures need to occur, and in how many minutes; before IIS shuts down the application pool which the worker processes are servicing.
  • You can also configure Startup Time Limit and Shutdown Time Limitsettings on the Health tab for worker processes that are not running as they should. The Startup Time Limit value indicates the time interval in which another worker process should replace an unhealthy worker process. The Shutdown Time Limit value indicates the time in which an unhealthy worker process can shut itself down, before IIS forcefully terminates it.

The Quality of Service (QoS) features of IIS

The various QoS features of IIS which you can enable and configure to tune IIS performance are listed below:


Comments

Please login to comment