Tuning Web Server Performance

Now that you know how to monitor your Web servers, let’s look at how you can tune the operating system and hardware performance. The areas I’ll examine are the following:

• Memory usage and caching

• Processor utilization

• Disk I/O

• Network bandwidth and connectivity

Monitoring and Tuning Memory Usage

Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. One of the key reasons memory can be such a problem is that the IIS file cache is configured to use up to half of the available system memory by default. This means that on a system with 512 MB of RAM, the IIS file cache could use as much as 256 MB of memory. (Of course, the amount of memory used for caching depends on the number of files and the frequency of requests.) IIS calculates its memory cache requirements every 60 seconds and makes any memory that isn’t required available for other applications.

To control the IIS file cache manually, add the Registry entry, MemCacheSize, as a REG_DWORD, and set its decimal value between 0 and 2500 MB at the following location:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \InetInfo \Parameters

Caching and virtual memory settings can also present a problem. Adding memory when there’s a caching or virtual memory problem on the server won’t solve performance problems. Because of this, you should always check for memory, caching, and virtual memory problems at the same time.

To rule out memory, caching, and virtual memory problems with the server, you should do the following:

• Configure application performance

• Configure data throughput

Once you’ve performed these tasks and rebooted the server, you can monitor the server’s memory usage to check for problems.

Setting Application Performance

Application performance determines the responsiveness of foreground and background applications that might be running on the system. In most cases you want a server to be equally responsive to foreground and background applications rather than give precedence to an application the Web administrator might be running on the computer. To ensure that the server is responsive to background applications, follow these steps:

1. Click Start, choose Control Panel, and then click System. This displays the System Properties dialog box.

2. Access the Advanced tab in System Properties and then display the Performance Options dialog box by clicking Settings in the Performance frame.

3. In the Visual Effects tab, you might want to select Adjust For Best Performance. This reduces the load on the system when displaying windows and menus.

4. In the Advanced tab, select Background Services. Ensure that under Adjust For Best Performance Of, System Cache is selected, and then click OK.

Setting Data Throughput

If you use the server primarily as a Web server, you should configure the server as an application server. This setting optimizes the server for networking performance, makes more memory available to Web applications, and enhances the server’s multiprocessor capabilities. To configure the server as an application server, complete the following steps:

1. Click Start and choose Control Panel, Network Connections, and finally Local Area Connection. The Local Area Connection Properties dialog box is displayed, as shown in Figure 13-11.

   
   Figure 13-11: Use the Local Area Connection Properties dialog box to configure file and printer sharing settings for the Web server.

   Note

   Servers with multiple network interface cards will have multiple network connections shown in Network And Dial-Up Connections. You should optimize each of these connections appropriately.

2. Select File And Printer Sharing For Microsoft Networks and then click Properties.

3. In the Server Optimization tab, select Maximize Data Throughput For Network Applications. Click OK twice.

4. You will need to reboot the server for these changes to take effect.

Checking Memory, Caching, and Virtual Memory Usage

Now that you’ve optimized the system, you can determine how the system is using memory and check for problems. Table 13-2 provides an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks. The table is organized by issue category.

Table 13-2: Uncovering Memory-Related Bottlenecks

Issue	Counters to Track	Details
Physical and virtual memory usage	Memory\Available Kbytes; Memory\ Committed Bytes	Memory\Available Kbytes is the amount of physical memory available to processes running on the server. Memory\Committed Bytes is the amount of committed virtual memory. If the server has very little available memory, you might need to add memory to the system. In general, you want the available memory to be no less than 5 percent of the total physical memory on the server. If the server has a high ratio of committed bytes to total physical memory on the system, you might need to add memory as well. In general, you want the committed bytes value to be no more than 75 percent of the total physical memory.
Memory caching	Memory\Cache Bytes; Internet Information Services Global\ Current File Cache Memory Usage; Internet Information Services;Global\ File Cache Hits %; Internet Information Services Global\ File Cache Flushes	Memory\Cache Bytes represents the total size of the file system cache. Internet Information Services Global\Current File Cache Memory Usage represents the current memory used by the IIS file cache. Internet Information Services Global\File Cache Hits % represents the ratio of cache hits to total cache requests and reflects how well the settings for the IIS file cache are working. A site with mostly static files should have a very high cache hit percentage (70-85 percent). Internet Information Services Global\File Cache Flushes tells you how quickly IIS is flushing files out of cache. If flushes are occurring too quickly, you might need to increase the time-to-live value for cached objects (ObjectCacheTTL). If flushes are occurring too slowly, you might be wasting memory and might need to decrease the time-to-live value for cached objects.
Memory page faults	Memory\Page Faults/sec; Memory\ Pages Input/ sec; Memory\ Page Reads/sec	A page fault occurs when a process requests a page in memory and the system can’t find it at the requested location. If the requested page is elsewhere in memory, the fault is called a soft page fault. If the requested page must be retrieved from disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults. Hard faults, however, can cause significant delays. Page Faults/sec is the overall rate at which the processor handles all types of page faults. Pages Input/sec is the total number of pages read from disk to resolve hard page faults. Page Reads/sec is the total disk reads needed to resolve hard page faults. Pages Input/sec will be greater than or equal to Page Reads/sec and can give you a good idea of your hard page fault rate. If there are a high number of hard page faults, you might need to increase the amount of memory or reduce the cache size on the server. Memory used by IIS can be controlled by the MemCacheSize and MaxCachedFileSize registry settings. If these entries are not added manually, and their values set in the registry, the default values are used.
Memory paging	Memory\Pool Paged Bytes; Memory\Pool Nonpaged Bytes	These counters track the number of bytes in the paged and nonpaged pool. The paged pool is an area of system memory for objects that can be written to disk when they aren’t used. The nonpaged pool is an area of system memory for objects that can’t be written to disk. If the paged pool’s size is large relative to the total amount of physical memory on the system, you might need to add memory to the system. If the nonpaged pool’s size is large relative to the total amount of virtual memory allocated to the server, you might want to increase the virtual memory size.

Monitoring and Tuning Processor Usage

The CPU does the actual processing of information on your server. As you examine a server’s performance, you should focus on the CPUs after memory bottlenecks have been eliminated. If the server’s processors are the performance bottleneck, adding memory, drives, or network connections won’t overcome the problem. Instead, you might need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity. You could also move processor-intensive applications, such as SQL Server, to another server.

Before you make a decision to upgrade or add CPUs, you should rule out problems with memory and caching. If signs still point to a processor problem, you should monitor the performance counters discussed in Table 13-3. Be sure to monitor these counters for each CPU installed on the server.

Table 13-3: Uncovering Processor-Related Bottlenecks

Issue	Counters to Track	Details
Thread queuing	System\Processor Queue Length	This counter displays the number of threads waiting to be executed. These threads are queued in an area shared by all processors on the system. If this counter has a sustained value of 10 or more threads, you’ll need to upgrade or add processors.
CPU usage	Processor\% Processor Time	This counter displays the percentage of time the selected CPU is executing a nonidle thread. You should track this counter separately for all processor instances on the server. If the % Processor Time values are high while the network interface and disk I/O throughput rates are relatively low, you’ll need to upgrade or add processors.
ASP performance	Active Server Pages\Request Wait Time; Active Server Pages\Requests Queued; Active Server Pages\ Requests Rejected; Active Server Pages\Requests/sec	These counters indicate the relative performance of IIS when working with ASP. Active Server Pages\Request Wait Time is the number of milliseconds the most recent request was waiting in the queue. Active Server Pages\Requests Queued is the number of requests waiting to be processed. Active Server Pages\Requests Rejected is the total number of requests not executed because there weren’t resources to process them. Active Server Pages\Requests/sec is the number of requests executed per second. In general, you don’t want to see requests waiting in the queue, and, if requests are queuing, the wait time should be very low. You also don’t want to see requests rejected because resources aren’t available. Keep these problems relative to the number of requests handled per second. You might notice some variance under peak loads. To resolve these issues you might need to upgrade or add processors.

Real World

In many cases a single server might not be sufficient to handle the network traffic load. If that happens, you might need to scale your site across multiple servers. For example, you could replicate the site to additional servers and then distribute the traffic across these servers using a load balancer. If you already have a multiple- server Web farm, you could add Web servers.

Monitoring and Tuning Disk I/O

With today’s high-speed disks, the disk throughput rate is rarely the cause of a bottleneck. That said, however, accessing memory is much faster than accessing disks. So if the server has to do a lot of disk reads and writes, the server’s overall performance can be degraded. To reduce the amount of disk I/O, you want the server to manage memory very efficiently and page to disk only when necessary. You monitor and tune memory usage as discussed previously in the “Monitoring and Tuning Memory Usage” section of this chapter.

Beyond the memory tuning discussion, you can monitor some counters to gauge disk I/O activity. Specifically, you should monitor the counters discussed in Table 13-4.

Table 13-4: Uncovering Drive-Related Bottlenecks

Issue	Counters to Track	Details
Overall drive performance	PhysicalDisk\% Disk Time in conjunction with Processor\% Processor Time and Network Interface \Bytes Total/sec	If the % Disk Time value is high and the processor and network connection values aren’t high, the system’s hard disk drives might be creating a bottleneck. Be sure to monitor % Disk Time for all hard disk drives on the server.
Disk I/O	PhysicalDisk\Disk Writes/sec; PhysicalDisk\Disk Reads/sec; PhysicalDisk\Avg. Disk Write Queue Length;PhysicalDisk\Avg. Disk Read Queue Length; Physical Disk\Current Disk Queue Length	The number of writes and reads per second tells you how much disk I/O activity there is. The write and read queue lengths tell you how many write or read requests are waiting to be processed. In general, you want there to be very few waiting requests. Keep in mind that the request delays are proportional to the length of the queues minus the number of drives in a redundant array of independent disks (RAID) set.

Note

Counters for physical and logical disks might need to be enabled before they’re available. To enable these objects, type the following commands at a command prompt:

Diskperf –y for a hard disk drive

Diskperf –yv for a software RAID set

Diskperf -? for a complete list of commands

Monitoring and Tuning Network Bandwidth and Connectivity

No other factor weighs more in a visitor’s perceived performance of your Web site than the network that connects your server to the visitor’s computer. The delay, or latency, between when a request is made and the time it’s received can make all the difference. If there’s a high degree of latency, it doesn’t matter if you have the fastest server on the planet. The user experiences a delay and perceives that your Web site is slow.

Generally speaking, the latency experienced by the user is beyond your control. It’s a function of the type of connection the user has and the route the request takes through the Internet to your server. Your server’s total capacity to handle requests and the amount of bandwidth available to your servers are factors under your control, however. Network bandwidth availability is a function of your organization’s connection to the Internet. Network capacity is a function of the network cards and interfaces configured on the servers.

A typical network card is equipped to handle a 100-megabit-per-second (Mbps) Fast Ethernet connection with fair efficiency, which is much more traffic than the typical site experiences and much more traffic than the typical server can handle. Because of this, your organization’s bandwidth availability is typically the limiting factor. If you have a shared T1 for all Internet activity, your servers are sharing the 1.544 Mbps connection with all other Internet traffic. If you have a dedicated T1 for your Web servers, your servers have 1.544 Mbps of bandwidth availability. If you have multiple T1s or a T3, the bandwidth available to your servers could range from 3 Mbps to 45 Mbps.

To put this in perspective, consider that the number of simultaneous connections your network can handle is relative to the speed of the connection, the average size of the data transferred per connection, and the permitted transfer time. For example, if you have a T1, the typical data transfer per connection (for a dial-up connection) is 50 kilobits per second (Kbps), and transfer time allowable is 15 seconds, your connection could handle this capacity:

• 30 data transfers per second (1544 Kbps / 50 Kbps), or

• 450 simultaneous transfers within 15 seconds (30 data transfers * 15 seconds)

On the other hand, if you have a T3, the typical data transfer per connection is 250 Kbps, and transfer time allowable is 15 seconds, your connection could handle this capacity:

• 180 data transfers per second (45,000 Kbps/ 250 Kbps), or

• 2700 simultaneous transfers within 15 seconds (180 data transfers * 15 seconds)

  Tip

  Your network card’s capacity can be a limiting factor in some instances. Most servers use 10/100 network cards, which can be configured in many ways. Someone might have configured a card for 10 Mbps, or the card might be configured for half duplex instead of full duplex. If you suspect a capacity problem with a network card, you should always check the configuration.

  Real World

  A T1 connection is a useful example for many commercial sites. Larger commercial sites are typically collocated at a hosting service, such as Genuity Managed Services, and might have 100 Mbps or greater connections to the Internet. If this is the case for your site, keep in mind that some devices configured on your network might restrict the permitted bandwidth. For example, your company’s firewall might be configured so that it allows only 5 Mbps for Web, 2 Mbps for FTP, and 1 Mbps for SMTP.

To determine the throughput and current activity on a server’s network cards, you can check the following counters:

• Network Interface\Bytes Received/sec

• Network Interface\Bytes Sent/sec

• Network Interface\Bytes Total/sec

• Network Interface\Current Bandwidth

If the total bytes-per-second value is more than 50 percent of the total capacity under average load conditions, your server might have problems under peak load conditions. You might want to ensure that operations that take a lot of network bandwidth, such as backups, are performed on a separate interface card. Keep in mind that you should compare these values in conjunction with PhysicalDisk\% Disk Time and Processor\% Processor Time. If the process time and disk time values are low but the network values are very high, there might be a capacity problem.

IIS provides several ways to restrict bandwidth usage and to improve bandwidth-related performance. These features are the following:

• Bandwidth throttling

• Connection limitations

• HTTP compression

Configuring Bandwidth Throttling and Connection Limits

You can restrict bandwidth usage by enabling bandwidth throttling and limiting the maximum number of allowable connections. Bandwidth throttling restricts the total bandwidth available to a service or individual sites. Connection limitations restrict the total number of allowable connections to a service. Because users might be denied service when these values are exceeded, you should enable these features only when you’re sure that this setting is acceptable.

Before you restrict bandwidth, you should monitor the network interface object counters discussed earlier in this chapter. If these counters indicate a possible problem, restricting bandwidth is one answer. You can configure bandwidth throttling for all Web sites on a server by completing the following steps:

1. In the IIS Manager snap-in, expand the node for the computer that you want to work with, right-click Web Sites, and then select Properties.

2. In the Performance tab, select the Limit The Total Network Bandwidth check box.

3. In the Maximum Bandwidth field, type the maximum number of kilobytes per second (Kbps) you want IIS to use. Remember, this value is for all Web sites.

4. Click OK.

To configure bandwidth throttling for individual Web sites, complete these steps:

1. In the IIS Manager snap-in, right-click the Web site you want to work with and then select Properties.

2. In the Performance tab, select Limit The Total Network Bandwidth.

3. In the Maximum Bandwidth box, type the maximum number of kilobytes per second you want the site to use.

4. Click OK.

Setting connection limits for Web and FTP sites was covered previously in this book. To learn how to configure limits for Web sites, see the section entitled “Restricting Incoming Connections and Setting Time-Out Values” in Chapter 3, “Configuring Web Sites and Servers.” For FTP sites, see the section of the same name in Chapter 9, “Managing FTP Servers.”

Configuring HTTP Compression

With HTTP compression enabled, the Web server compresses files before sending them to client browsers. File compression reduces the amount of information transferred between the server and the client, which in turn can reduce network bandwidth usage, network capacity, and transfer time. For HTTP compression to work, the client browser must support HTTP 1.1 and this feature must be enabled. Although most current browsers support HTTP 1.1 and have the feature enabled by default, older browsers might not support HTTP 1.1. Older browsers will still be able to retrieve files from your site, but they won’t be taking advantage of HTTP compression.

Before you enable compression, you should monitor the current processor usage on the server. HTTP compression adds to the overhead on the server, which means that it will increase overall processor utilization. If your site uses dynamic content extensively and process utilization (% Processor Time) is already high, you might want to upgrade or add processors before enabling HTTP compression.

Once you’ve completed your processor evaluation and have decided to use HTTP compression, you can enable this feature by completing the following steps:

1. In the IIS Manager snap-in, expand the node for the computer that you want to work with, right-click Web Sites, and then select Properties.

2. Select the Service tab, as shown in Figure 13-12.

   
   Figure 13-12: Use the Service tab to configure HTTP compression.

3. To compress dynamic content, such as ASP, select Compress Application Files. Compressed dynamic files are stored in memory.

4. To compress static files, such as Hypertext Markup Language (HTML) pages, select Compress Static Files. Compressed static files are stored on disk in the directory specified by the Temporary Directory field.

5. You use the Temporary Directory field to specify where compressed static files are stored until the time-to-live period expires. When using compression for static files, type the name and path of the directory you want to use. Or click Browse to locate a directory where compressed files will be stored.

   Note

   The directory must be on a local drive on a NTFS file system (NTFS) partition. In addition, the directory shouldn’t be shared and can’t be a compressed directory.

6. To limit the size of the static file cache, select Limited To, and then type a limit in megabytes for the directory.

7. Click OK.