Microsoft IIS 6.0Administrator's Consultant

Previous chapters in this part of the book focused on techniques you can use to monitor Internet Information Services (IIS) and to optimize server hardware. In this chapter you’ll learn how to optimize IIS and its related services. You’ll learn techniques for improving IIS performance, configuring automatic restarts of IIS, and getting the most from IIS applications. You’ll also learn advanced techniques for managing IIS through the Microsoft Windows Registry and the IIS metabase.

The Windows Registry contains configuration settings for the operating system, the server hardware, and all applications installed on the server, including IIS. The metabase contains configuration settings that are specific to the sites and virtual servers you’ve implemented on a particular server. Although you can manage most configuration settings through the IIS properties dialog boxes, you can change some properties only through editing the registry or the metabase directly. These settings typically are advanced values that you should change only when you have unique needs.

Strategies for Improving IIS Performance

In this section I examine strategies you can use to improve the performance of IIS. The focus of this section is on improving the overall responsiveness of IIS and not the underlying server hardware.

Removing Unnecessary Applications and Services

One of the most obvious ways to improve IIS performance is to remove resource drains on the server. Start by removing applications that might be affecting the performance of IIS, including:

• Microsoft SQL Server

• Microsoft Exchange Server

• File and print services

• UNIX services

If necessary, move these applications and services to a separate server. This will give IIS more resources to work with. For applications that you can’t move, see if there’s a way to run the applications only during periods of relatively low activity. For example, if you’re running server backups daily, see if you can schedule backups to run late at night when user activity is low.

System services are another area you can examine to see if there are unnecessary resource drains. Every service running on the server uses resources that can be used in other ways. You should stop services that aren’t necessary and set them to start manually. Before you stop any service, you should check for dependencies to ensure that your server isn’t adversely affected.

If you have a dedicated IIS server, the following services aren’t required in most instances:

• Alerter

• Automatic Updates

• ClipBook

• Computer Browser

• DHCP Client

• DHCP Server

• Fax Service

• File Replication

• Infrared Monitor

• Internet Connection Firewall (ICF) / Internet Connection Sharing (ICS)

• Messenger

• NetMeeting Remote Desktop Sharing

• Network DDE

• Network DDE DSDM

• Print Spooler

• TCP/IP NetBIOS Helper

• Telephony

• Telnet

• Themes

• Uninterruptible Power Supply

• Wireless Configuration

Optimizing Content Usage

Your server’s responsiveness is tied directly to the content you’re publishing. You can often realize substantial performance benefits by optimizing the way content is used. IIS can handle both static and dynamic content. Although static content is passed directly to the requesting client, dynamic content must be processed before it can be passed to the client. This places a resource burden on the server that you can reduce by using static content.

When you use static content, keep in mind that you should set expire headers whenever possible. Expire headers allow the related files to be stored in the client’s cache, and this can greatly improve performance on repeat visits when the original content hasn’t changed. For details on setting expire headers, see the section entitled “Customizing Web Site Content and HTTP Headers” in Chapter 4, “Customizing Web Server Content.”

With dynamic content, you should limit your use of Common Gateway Interface (CGI) applications. CGI applications require more processor and memory resources than their Internet Server Application Programming Interface (ISAPI), Active Server Pages (ASP), and ASP.NET counterparts. Because of this, you should replace or convert CGI applications to ISAPI, ASP, or ASP.NET.

Whenever you work with ISAPI, ASP, or ASP.NET applications, try to push as much of the processing load onto the client as possible. This reduces the server resource requirements and greatly improves application responsiveness. One example of pushing processing to the client is to use client-side scripting to evaluate form submissions before data is sent to the server. This technique reduces the number of times information is sent between the client and the server; therefore, it can greatly improve the application’s overall performance.

To improve content-related performance, you might also want to do the following:

• Analyze the way content is organized on your hard disk drives In most cases you should keep related content files on the same logical partitions of a disk. Keeping related files together improves IIS file caching.

• Defragment your drives periodically Over time, drives can become fragmented, and this decreases read/write performance. To correct this, defragment your server’s drives periodically. Many defragmentation tools allow you to automate this process so that you can configure a scheduled job to automatically defragment drives without needing administrator intervention.

• Reduce the size of content files The larger the file size, the more time it takes to send the file to a client. If you can optimize your source Hypertext Markup Language (HTML) or ASP code and reduce the file size, you can increase your Web server’s performance and responsiveness. Some of the biggest bandwidth users are multimedia files. Compress image, video, or audio files using an appropriate compression format whenever possible.

• Store log files on separate disks from content files Logging activity can reduce the responsiveness of a busy server. One way to correct this is to store access logs on a different physical drive from the one storing your site’s content files. In this way, disk writes for logging are separate from the disk reads or writes for working with content files, which can greatly improve the overall server responsiveness.

• Log only essential information Trying to log too much information can also slow down a busy server. With the World Wide Web Consortium (W3C) extended logging format, you can reduce logging overhead by logging only the information that you need to generate reports and by removing logging for nonessential information. With any type of logging, you can reduce logging overhead by organizing different types of content appropriately and then disabling logging on directories containing content whose access doesn’t need to be logged. For example, you could place all your image files in a directory called Images and then disable logging on this directory.

  More Info

  Techniques for configuring logging are discussed in Chapter 14, “Tracking User Access and IIS Logging.” If your organization has large IIS installations running dozens or hundreds of IIS sites per server, you should consider using centralized binary logging, which is also discussed in Chapter 14.

Optimizing ISAPI, ASP, and ASP.NET Applications

Improperly configured and poorly optimized applications can be major resource drains on an IIS server. To get the most from the server, you need to optimize the way applications are configured. Do the following to optimize applications:

• Enable ISAPI application caching IIS can cache ISAPI applications in memory. This allows frequently used applications to be accessed quickly. You can control caching with the metabase property CacheISAPI.

• Manage application buffering and flushes appropriately Application buffering allows all output from an application to be collected in the buffer before being sent to the client. This cuts down on network traffic and response times. However, users don’t receive data until the page is finished executing, which can give the perception that a site isn’t very responsive. You can control application buffering with the metabase property AspBufferingOn.

• Disable application debugging Application debugging slows IIS performance considerably. You should use debugging only for troubleshooting. Otherwise, you should disable debugging. You can control debugging with the metabase property AppAllowDebugging.

• Optimize application performance You can configure ASP and ASP.NET applications to shut down idle processes, limit memory leaks and outages, and rapidly detect failures. For more information, see Chapter 6, “Managing ASP.NET, Application Pools, and Worker Processes.”

• Manage session configuration appropriately As the usage of your server changes, so should the session management configuration. By default, session management is enabled for all applications. If your applications don’t use sessions, however, you’re wasting system resources. Instead of enabling sessions by default, you should disable sessions by default and then enable sessions for individual applications. You can control sessions with the metabase properties AspAllowSessionState, AspSessionMax, and AspSessionTimeout.

• Set a meaningful session time-out The session time-out value is extremely important in determining the amount of resources used in session management. Set this value accurately. Sessions should time out after an appropriate period. Configure session time-out with the metabase property AspSessionTimeout.

• Set appropriate script and connection time-out values ASP scripts and user connections should time out at an appropriate interval. By default, ASP scripts time out after 90 seconds and user connections time out after 2 minutes. Zombie scripts and open connections use resources and can reduce the server’s responsiveness. To reduce this drain, set appropriate time-outs based on the way your site is used. You can control script and connection time-outs with the metabase properties AspScriptTimeout and ConnectionTimeout, respectively.

Optimizing IIS Caching, Queuing, and Pooling

IIS uses many memory-resident caches and queues to manage resources. If you make extensive use of dynamic content or have a heavily trafficked site, you should optimize the way these caches and queues work for your environment. You might want to do the following:

• Consider changing application pool queue length Whenever requests for applications come in, the HTTP listener (Http.sys) picks them up and passes them to an application request queue. To prevent large numbers of requests from queuing up and flooding the server, each application request queue has a default maximum on the amount of concurrent requests. If this value doesn’t meet your needs, you can modify it using the metabase property AspRequestQueueMax. In most cases you’ll want to set this value to the maximum number of connection requests you want the server to maintain.

• Consider changing the maximum entity size By default, IIS limits the maximum number of bytes allowed in the entity body of an ASP request but doesn’t limit the size of other types of requests. To control the maximum entity size, you use the metabase properties AspMaxRequestEntityAllowed and MaxRequestEntityAllowed.

• Consider disabling thread pooling for CGI By default, long-running CGI requests can use a server pool thread. If you make extensive use of CGI applications, you might want to examine performance with and without thread pooling, and then determine which method works best for your server.

• Consider changing connection queue length When you use HTTP keep-alives, IIS maintains connections for a user’s HTTP session in a connection queue. By default, this queue can hold a maximum of 25 connections at any one time. With application pools and queuing, the need for the connection queue is reduced. Still, on a server with a very heavy load and high traffic you might want to increase the connection queue’s size. To do this, set the Windows Registry value ServerListenBackLog.

• Consider changing the IIS File Cache settings By default, IIS uses up to 50 percent of the server’s available physical memory. This value ensures that IIS works well with other applications that might be running on the server. If the server is dedicated to IIS or has additional memory available, you might want to increase this setting to allow IIS to use more memory. To control IIS file caching, you create and then set the Windows Registry value MemCacheSize.

• Consider changing the maximum cached file size By default, IIS caches only files that are 256 KB or less in size. If you have large data or multimedia files that are accessed frequently, you might want to increase this value to allow IIS to cache larger files. Keep in mind that with file sizes over 256 KB you’ll reach a point at which caching won’t significantly improve performance. The reason for this is that with small files the overhead of reading from disk rather than the file cache is significant, but with large files the disk read might not be the key factor in determining overall performance. To control the maximum cached file size, you create and then set the Windows Registry value MaxCachedFileSize.

• Consider adjusting the Time to Live (TTL) value for cached resources By default, IIS purges from cache any resources that haven’t been requested within the last 30 seconds. If you have additional memory on the server, you might want to increase this value so that files aren’t removed from cache as quickly. To control the TTL value for cached resources, you create and then set the Windows Registry value ObjectCacheTTL.

  Tip

  If you have a dedicated server running only IIS, you might want to consider allowing resources to remain in cache until they are overwritten (due to MemCacheSize limits). In this case, you would set ObjectCacheTTL to Unlimited (0xFFFFFFFF).

• Consider modifying the ASP template cache The ASP template cache controls the number of ASP pages that are cached in memory. By default, IIS will cache up to 500 files. This might not be enough on a site with lots of ASP content. Template cache entries can reference one or more entries in the ASP Script Engine Cache. To control template caching, you set the metabase property AspScriptFileCacheSize.

• Consider modifying the script engine cache The ASP Script Engine Cache is an area of memory directly accessible to the scripting engines used by IIS. As such, the preferred area for IIS to retrieve information from is the script engine cache. By default, the script engine cache can hold up to 250 entries. To control script engine caching, you set the metabase property AspScriptEngineCacheMax.

  More Info

  To learn more about editing the cache settings in the Windows Registry, see Chapter 13, “Performance Tuning and Monitoring.”

Configuring Automatic Restarts of IIS

Chapter 2, “Core IIS Administration,” focused on core administration tasks for IIS. In that chapter you learned how to manage services and how to use the IIS Reset utility. To get the best performance from IIS, configure the IIS Admin Service to run the IIS Reset utility automatically if a problem occurs with the service. This allows IIS to recover automatically from most situations that otherwise would have stopped IIS from handling user requests altogether.

You can configure automatic restart of IIS by completing the following steps:

1. From Administrative Tools, start the Computer Management console, and then connect to the computer whose services you want to manage.

2. Expand the Services And Applications node by clicking the plus sign (+) next to it and then select Services.

3. Right-click IIS Admin Service and then select Properties.

4. Select the Recovery tab. Set the First Failure, Second Failure, and Subsequent Failures fields to Run A Program, as shown in Figure 15-1.

   Figure 15-1: Configure the IIS Admin Service to run the IIS Reset utility.

5. In the Program field of the Run Program frame, type \%SystemRoot%\ System32\ Iisreset.exe.

6. Click OK.