 | ||
|
| ||
| ||
|
| ||
Mary Haggard
Program Manager
Microsoft Corporation
April 14, 1998
The following article was originally published in Site Builder Magazine (now known as MSDN Online Voices).
Once upon a time, when Web pages consisted only of HTML and a few graphics, one Web server and a fast Internet connection could take care of all of the requests that the majority of Web sites received. However, as server-intensive Web applications become more commonplace, and the Internet and intranets are expected to tie into other systems, the time of easy Web-server maintenance is fading.
Windows NT Server's performance monitoring tools, such as Performance Monitor, Task Manager, PerfLog, and Web Capacity Analysis Tool (WCAT), provide a familiar interface to monitor performance on the Web server. Use them to help diagnose problems related to the five fundamental aspects of the Web server: processor, memory, disk, network, and Internet Information Server (IIS). Because performance-monitoring tools require bandwidth, use them sparingly on your live service.
For anyone serious about deploying a Web server on the Internet or on an intranet, a must-buy book is the Internet Information Server Resource Kit 
(new for IIS version 4.0, and available from Microsoft Press). It includes chapters on Optimizing and Tuning IIS, building server-based Web applications, migrating existing Web servers to IIS, tying IIS servers to ODBC databases and legacy systems, and capacity planning -- as well as special sections for ISPs on installing and configuring IIS for the ISP environment. The CD-ROM also contains tools and utilities (including the WCAT tool mentioned above), sample applications, and source code to help augment topics within the book. Detailed information about almost everything I discuss in the rest of this chapter is available in the Internet Information Server Resource Kit.
You can monitor Network traffic with the TCP/IP monitoring capabilities of the Windows NT Performance Monitor and Netmon utilities. However, because many of the hardware and software components that affect network capacity are out of your control, monitoring and controlling network issues on the Web server can be tricky. Adding to that complexity is the fact that clients will tend to see problems with bandwidth shortages on your site way before your Web server will pick up any issues. Even if clients are getting time-out errors or experiencing slow connections, the server may not recognize the problem. Use Performance Monitor to track the success of TCP connections with Windows NT,. but don't use the performance tools as your only source of performance measurement. Keep in contact with the folks who gather and process site feedback to help find site-performance problems.
To increase the amount of data that can come from the machine, add multiple 32-bit network cards (one per processor). If much of your server traffic is HTML files, your most likely problem will be saturation of the network connection itself. Watch transmission rates, file transfers, TCP connections, and bandwidth throttling (if enabled) when monitoring network capacity and bandwidth. If your monitoring tools or site feedback seem to show you are using all of your network bandwidth for more than a few minutes a day, it's time to think about a connection upgrade.
Upgrading the connection can be a costly step. If you need to make-do temporarily with your current bandwidth, try cutting the number of files per page-request in your pages. For instance, if you build one HTML page with 30 graphics, you are effectively making 31 requests to the server for files. When a Web server must download this many graphics for one page request, and the connection is near its limit, network saturation problems can occur. Cutting the number of graphics on the pages, or making those graphics smaller or simpler, can buy you some time before a costly network connection upgrade.
Because IIS handles file caching very well, a Web server rarely has memory problems that aren't solved easily by adding more RAM to the machine or adjusting the way the machine uses memory. Frequently accessed files and objects are kept in the File System or Object Caches, and Windows NT Server takes care of updating each when files or objects change. Settings on these system caches can be adjusted. Memory issues can be perceived as performance problems in other components (like disks and processors), and it's important to rule out memory as the troublesome performance factor before going down other paths. Monitor the IIS Object Cache and the File System Cache with Performance Monitor. Be sure you don't add so much memory that the increased throughput causes you to exceed the limitations of your network connection.
Processor bottlenecks occur when one or more processes occupy nearly all of the computer's processor time. Bottlenecks can occur on single- or multiple-processor machines. Like memory, the available processors must support the activities of the entire Windows NT machine, so monitoring and adjusting processor issues must be done with an eye to the entire system. Memory bottlenecks often appear to be processor related, so be sure that your memory requirements are being met before adding disks or processors to the system. Also, poorly written code can cause performance problems for the processors by throwing off load balancing, so be sure code isn't the performance issue. Monitor processor activity, connections, IIS threads, and work distribution to find processor-related problems.
You can set some Windows NT services to manual status, or even disable them completely, to help improve IIS performance on your server. Of course, not all of these will apply in all cases (sometimes the Web server is also performing other functions), but the following services are always required.
New technologies that allow the development of powerful Web applications can also be very server intensive. Documentation that gives tips on how to write the best code is just becoming available. Here is a bulleted list of things to keep in mind, but this is only a start. The source of these tips, and dozens more, is the Server section of the MSDN Online Web Workshop. The Internet Information Server Resource Kit also contains helpful information on how to organize ASP script code for optimal performance.
By remembering these tips, you can save yourself headaches when writing and implementing Web applications on IIS. Documentation that you find on writing good ASP code is well worth the time it takes to research. In fact, by just implementing a few of the tips above, the folks on the Internet Start Web site doubled the performance of their server code.
If you expect a high amount of traffic between your Web servers and ODBC database applications or other systems -- such as a commerce system -- consider running those processes on machines separate from your Web server to optimize performance. If they are on the same machine as the Web server, those types of applications can stress the Web server and force it to support a smaller number of users. By dividing the tasks between multiple machines, you can optimize for the number of expected users, and optimize the hardware required for the tasks that each process performs. You will need to plan adequately for all the machines you'll need, and to ensure the network connections and code running between them are high performance.
Test Web applications for performance before they are launched. Simulate client requests, and monitor the server performance while applications are running. Then monitor the server without the applications running, and determine what effects the application has on overall server performance. Use WCAT, which comes with the IIS Resource Kit, and Performance Monitor during these simulations.
Security features on the Web server (encrypted transactions, user authentication, and others) take time to process, and can seriously affect performance of the Web server. Because security features of IIS are tightly integrated with those of Windows NT, you can not monitor them separately from other aspects of the server. Instead, run tests comparing the server performance with and without the security features. Measure processor activity, memory used, and network activity with and without the features enabled, and carefully study your security strategy to ensure you are implementing tight enough, but not overly excessive, security precautions. For instance, be sure that only pages or portions of pages that really need encrypted transactions are encoded.
Despite their performance cost, dynamic server-based Web pages and applications are continuing to increase in popularity, and to constitute an ever-larger proportion of the average Web server file base as the technology develops. The challenge for administrators is to preserve speed and efficiency while publishing more complex pages.
The task of running and maintaining a Web server is not an easy one. Be sure that you arm yourself with the tools you need to do your job right. That includes the Windows NT Server documentation, the Windows NT and IIS Resource Kits, and an understanding of TCP/IP networking issues.
Since taking early retirement as commander of the Starship Enterprise, Mary Haggard has worked her way through the ranks at Microsoft. As a program manager, she helped launch the Microsoft MSDN Online Network Web site and the Microsoft Internet Explorer Channel Guide. She is the author of Survival Guide to Web Site Development (Microsoft Press), based on this series of columns. Mary once worked in a paper mill, so she knows pulp when she sees it.
Now in bookstores: Survival Guide to Web Site Development, Mary Haggard's new book from Microsoft Press, inspired by this series of columns in MSDN Online Network Magazine! Make Mary's day: Buy the book.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top