IIS 101: The Basics of Performance Tuning

IIS 101

When you tune a server, you’re adjusting the settings and configuration of that server for optimum performance in a given task. This topic is one of my favorites because it requires that you understand not only IIS but also the hardware and server configuration. Seemingly minor adjustments can have major effects—for better and for worse.

As with most technical subjects, you can achieve the greatest benefit with the same few adjustments, so I talk about those adjustments along with some tips for troubleshooting and testing Web server performance.

Hardware
Before I talk about server and Web server adjustments, let me say a few words about the hardware—the computer and components that run the OS. This topic really comes under the category of scaling, but I mention it here because it’s directly related to performance.

A common question is, "Can my server handle the load the way I’ve configured it?" This question isn’t easy to answer, but here are a few guidelines.

First, a modest server can manage more than you think. I commonly encounter IIS administrators who tell me that they have 600 or more Web sites on a 256MB, 350MHz Pentium II machine and get good performance.

Second, RAM is the most important player when it comes to performance. The bigger the load, the more RAM you need. The reason for extra RAM is file and object caching. The IIS file cache can use up to 4GB of RAM for caching. If you serve mostly static content, you want enough RAM to hold your most frequently accessed pages.

Third, the most significant help is faster CPUs. CPUs are important in sites that deliver dynamic content or in sites in which Secure Sockets Layer (SSL) is a big factor. Note that I didn’t say "more CPUs." To some extent, having more CPUs can help, but CPUs with larger L2 caches will improve performance significantly. In other words, you might see more benefit from a single Xeon processor with a 2MB L2 cache than from multiple Pentium II machines.

Hard disk performance is the least likely candidate to be a benefit in tuning. The main reason that hard disks should be have a low impact on performance is that most of your HTML files should be cached in RAM. In database-bound applications, you need enough RAM to cache your database files as well as your HTML files. In other words, you must provide enough RAM and processing power to deliver gigabytes of data from RAM. This rule is the foundation of Windows 2000 Datacenter Server.

If you need to increase hard disk performance, RAID arrays perform better than single hard disks. However, don’t implement RAID in software: Buy a RAID controller. It’s well worth the investment to offload the task of managing the array from the CPU.

Finally, NICs are a significant player. With Web servers that serve mostly static content, the network is the most likely bottleneck you encounter. In Win2K, you can improve NIC performance by purchasing cards that support TCP checksum offloading. Offloading helps move some CPU-intensive tasks to the NIC, thereby improving throughput. Also, with more advanced NICs, you can assign them to a particular processor in a multiprocessor system, which can help performance in some situations (e.g., in installations in which network load is intensive and must be load-balanced among processors). Refer to the Microsoft Windows 2000 Resource Kit for more information about hardware performance tuning.

Tuning the OS
The first setting to adjust on your system is how you set up the server to prioritize caching. To optimize your system, right-click Network Neighborhood, then select Properties. Click the Services tab. Highlight Server, then click Properties to access the Server dialog box, which Figure 1 shows. On the Server dialog box, select Maximize Throughput for Network Applications. This setting biases the server to keep applications in memory rather than swap them out to make room for file caching. IIS doesn’t perform well when the Virtual Memory Manager (VMM) swaps IIS to the paging file.

Win2K has a similar tuning setting that you can find by right-clicking My Network Connections, then selecting Properties, Microsoft File and Print Sharing Properties. Click the Server Optimization tab, and choose Maximize Data Throughput for Network Operations.

Win2K has another adjustment that lets you prioritize the foreground and background operations. For IIS servers, set this optimization to Background services, as Figure 2 shows. To access the Performance Options dialog box, click Start, Settings, Control Panel, System. On the System dialog box, click the Advanced tab, then click Performance Options. (A similar setting exists in the same location for NT 4.0.)

Tuning IIS
The first rule in tuning IIS is to use only what you need. You might be expecting a lot of details about obscure registry settings. Although there are tuning parameters that you can adjust only in the registry, IIS tuning is mostly self-maintaining and thus should be left alone for the vast majority of sites. You can spend a lot of time tweaking settings to gain only a 10 percent increase in performance. In some cases, you’ll make matters worse. Advanced tuning is a case of monitor-tweak-monitor-tweak. Of course, this kind of tuning isn’t practical on a production server, so you must simulate it, and usually that process is neither simple nor fast.

My preference is to go for the easiest, fastest gains, then see whether you need more. Setting up your server correctly and having enough of the right hardware is more than half the battle. The other half lies in simply not installing features you don’t require, such as Microsoft Index Server on IIS 4.0. If you install Index Server, disable indexing on all sites and folders that you don’t want included. Figure 3 shows the Properties dialog box for the Default Web Site on IIS 5.0, on which I’ve enabled indexing. (On my systems, I always disable indexing on the Default Web Site because I use the Default Web Site only to access documentation.)

Logging
Logging is another activity that you can disable on a Web site, directory, or file basis. For example, you might not be interested in knowing that redball.gif was downloaded 3000 times in January. Some sites group all incidental graphics in a folder, and you disable logging for that folder. Remember that logging provides important security-related information, so it should always be on where content is a security risk (e.g., on a folder that contains programs or access to system functions).

Logging of IIS activity is disk intensive. To help the logging performance, move the log folders to a drive other than the Web server. In this way, logging activity doesn’t interfere with the file access that the Web server requires.

The Performance Tab
An obvious place from which to tune IIS is the Performance tab on the Properties dialog box of any Web site. On that tab, you’ll find the Performance tuning slider that Figure 4 shows. You can use this slider to adjust the cache settings for individual Web sites. Set low-volume sites at the lowest setting to free resources for other purposes. Be aware that socket pooling in IIS 5.0 can cause you to adjust the performance tuning settings for all the Web sites that use the same port as the Web site you’re adjusting (typically, port 80). In other words, because of this confusing and underdocumented "feature" of IIS 5.0, you might be adjusting many Web sites when you think you’re adjusting only one Web site. For more information about IIS performance tuning, see the sidebar "Related Reading."

Running in Process
Running in process means that a Web site runs as a task within IIS (inetinfo.exe). You can elect to run a Web site either in process or out of process. (In IIS 5.0, there is a third setting—"pooled out of process"—which is an intermediate setting between the two.)

Running a Web site in process delivers faster performance than any other setting. In process is the preferred setting for sites that deliver only static content. In process is also the preferred setting if you have sites that deliver dynamic content and are proven stable. Placing a Web site that uses scripting or programs to serve pages in process can be risky because the Web server will fail if the programs or objects that the Web site calls fail. You can change the in-process setting for any Web site on the Home Directory tab of the Web site’s Properties dialog box.

ASP Settings
Here are a few recommendations for sites that use Active Server Pages (ASP). You can find all these settings in the Application Settings dialog box that Figure 5 shows. You can access this dialog box by clicking Configuration on the Home Directory tab of the Web site’s Properties dialog box.

On the App Mappings tab, select the Cache ISAPI applications check box. This setting caches ASP engines when they’re called and facilitates throughput significantly. On the Application Mappings window, remove every entry that you’re not specifically using. (This step isn’t so much for performance as for security.)

On the App Options tab, which Figure 6 shows, match the settings that the figure shows, if possible. Your application might require that you enable session state for the Web site. If so, your developers can advise you on this setting. However, you can then advise your developers to stop using session state for many good reasons. (See the article "ASP Commandment #7: No COM Objects in Sessions" at http://www.learnasp.com/learn/nosessionobjects.asp.) Buffering should remain on, but disable parent paths for security reasons.

On the App Debugging tab, disable debugging. You can enable debugging during development, but be sure to disable it on your production servers. When debugging is on, ASP requests are serialized, which means that performance is going to be poor.

Covering the Basics
A great many other topics exist on this subject. I just covered the basics. Fortunately, some good references on tuning and monitoring IIS exist. For a list of these resources, see the sidebar "Performance Tuning Resources."