In the Internet server world, Web managers need to know how to achieve the best possible performance with the hardware and software at their disposal. This task is often more difficult than most managers expect and requires a great deal of testing and research. Let's dive beneath the surface of this vast and confusing subject so you can formulate a plan for optimizing your Web site.
Determining a Performance Baseline
Before you start testing and tuning servers, you need to determine a reasonable performance baseline for your Web site. You need to consider the type of content you serve and the service level customers expect. For example, a customer who clicks a link to get a local newspaper article expects the page to appear faster than does a customer who requests a copy of his or her bank transactions for the past 60 days. In the latter case, a customer might expect to wait 10 to 15 seconds for the response, whereas the customer trying to connect to the newspaper article might become frustrated after 7 seconds. Keep in mind that different areas of the site might require different baselines. This fact is especially important for servers that host multiple sites.
After you determine a site's performance baseline, you might need to break down the site's functionality into categories so that you can measure each part accurately. For example, if your Web server returns data from a back-end Microsoft SQL Server and takes 10 seconds to serve a page, you'll need to determine whether the Web server or the SQL Server is causing the bulk of the delay. Although you'll likely be able to achieve performance gains from both the Web server and SQL Server, knowing which server is causing the largest share of the delay will tell you which server offers the greatest potential for overall performance improvement.
Stress Testing
Next, you'll gather the Web site's performance data. In some cases, you'll stress-test a site before you put it into production; in others, you'll directly monitor production servers. When you stress-test a site, create the most realistic environment possible. Too often, I see companies stress-test with positive results, only to have the server fail as soon as it goes live because the test environment didn't represent a real-world situation. Make sure test client machines have adequate power—if clients are underpowered, they can't push the servers to the limit in a stress test.
Microsoft and several third-party vendors offer simulation tools you can use to stress-test your servers. Microsoft offers the Web Capacity Analysis Tool (WCAT) and the Web Application Stress (WAS) tool, which the company recently enhanced and repackaged as Visual Studio .NET's Application Center Test tool. The Microsoft Application Center Test tool provides comparative performance-run analyses. For information about this tool, visit http://webtool.rte.microsoft.com. The WCAT and WAS tool ship on the Microsoft Windows 2000 Server Resource Kit CD-ROM, along with documentation for using them. Be sure to consider a wide range of test scenarios as you create the test scripts.
Monitoring Web Site Performance
When you're ready to test your server, and when your server is in production, you'll need to monitor its performance. For more information about performance-testing your systems, see "Performance-Troubleshooting Resources." The most widely used monitoring tool is Performance Monitor, which is built in to all Windows NT—based OSs. This article assumes you know how to use Performance Monitor and discusses how to interpret Performance Monitor's results. If you're unfamiliar with this tool, read the Microsoft article "HOW TO: Manage Performance Monitor Counters in Windows 2000 (http://support.microsoft.com/?kbid=302521) for an overview.
To determine which parts of your system you need to tune, you'll need to monitor several functional areas of IIS and NT, including memory, processor, hard disk, and network performance, and various software functions on the Web site, such as Active Server Pages (ASP) processing time, IIS caching, and back-end processing times. The following list outlines a few of the Performance Monitor counters you can use.
- Memory: Available Bytes—This counter measures the memory available to run applications. You don't want this value to fall below 5 to 10 percent of the total computer memory.
- Process: Working Set: Inetinfo—This counter measures the amount of memory (including paged memory) that Inetinfo is using. This amount includes the cache memory and connection memory.
- Memory: Page Faults/sec: Inetinfo—This counter measures the rate (page faults/sec) at which requested memory isn't at the specified location. This counter includes times when the system has to go to the swap file to retrieve memory. After you determine an average Inetinfo Working Set size for your server's load, see whether you can lower the Page Faults by adding more RAM, thus keeping more of the Working Set in memory.
- Internet Information Services Global: File Cache Hits %—This counter measures the ratio of successful retrievals from cache (for static content) versus the number of requests made to the cache. A value of 80 to 90 percent for a static heavy site is considered good.
- Internet Information Services Global: File Cache Flushes—This counter measures the number of times an item is flushed from the cache. Keep in mind that IIS can flush items from the cache because of a timeout or because the content changes.
- Internet Information Services Global: File Cache Hits—This counter measures the number of times that items are retrieved from the cache. Compare this number with the File Cache Flushes figure. If your flushes are more than 50 percent of the number of hits, you might need to increase the cache size. If your flushes are less than 15 percent of the number of hits, you might be wasting memory.
- Processor: % Processor Time—This counter measures the percentage of time that the processor is working versus being idle. A sustained value of more than 80 percent can indicate a processor bottleneck.
- Thread: Context Switches/sec—This counter measures the number of context switches per second. A context switch occurs when one thread stops executing on the processor and another thread starts. On an idle processor, you might see as many as 800 to 1000 context switches per second, and on a busy machine, the count can increase to a few thousand. If a busy machine shows more than five times the number of switches than when the processor is idle, you might be seeing a bottleneck.
- Active Server Pages: Requests/sec—This counter measures the number of ASP requests coming in to IIS. This counter doesn't include static requests or requests for other dynamic data.
- Active Server Pages: Requests Executing—This counter measures the number of ASP requests being processed in the ASP thread pool.
- Active Server Pages: Request Wait Time—This counter measures the amount of time (in milliseconds) that the most recent request waited in the request queue.
- Active Server Pages: Request Execution Time—This counter measures the amount of time (in milliseconds) that the most recent request took to process.
- Active Server Pages: Requests Queued—This counter measures the number of requests currently waiting in the ASP queue.