You can't optimize Web server performance single-handedly. Making sure that your hardware is up to the task and your servers are properly configured is vital to maximizing performance. But if developers don't keep performance in mind as they design, write, and test an application, all hardware adjustment and server configuration will be for naught.
Optimum performance results only when you maximize development, hardware, and configuration. Case in point: A client hired a consultant to develop an intranet application to run on Microsoft Internet Information Server (IIS) 4.0 and Microsoft SQL Server 6.5. The application was slow, and the client complained to the consultant. The consultant said the application was slow because the hardware was inadequate. So, the client replaced his database server with a fast industry-standard server and added memory and a faster hard disk to the application server. However, the application's performance improved only slightly.
Several problems existed, but hardware wasn't one of them. Most of the problems resulted from poor design and development. The developers chose ActiveX documents for the UI, which made the application slow to load on client machines and required more client overhead than HTML. The database had few—and often incorrect—indexes. Poor coding meant that populating a tree control on the intranet application took as many as 20 seconds. The application did little processing on the server, and the client couldn't load-balance the application across servers because doing so required users to visit the same Web server with each successive request. To run well, the application needed extensive redesign.
Like this client, too many systems administrators and developers take the hit-or-miss approach to performance. Hardware certainly plays an important part in optimizing Web site performance, as does IIS configuration. But developers must also design performance into their applications.
Systems administrators have varying control over these performance factors. However, the applications that perform best usually result from systems administrators, Web masters, and application developers working together on application design, testing, and implementation. Because developers don't typically design an application with performance in mind, a systems administrator needs to know enough about application development to be able to ask the right questions and make intelligent suggestions for better performance.
The Development Cycle
The earliest and most basic development decisions play an important role in application performance. Systems administrators and other team members must be prepared to offer recommendations about decisions such as what hardware to use, whether to use Windows 2000 or Windows NT, and whether to implement the application through either Visual Basic (VB) with Active Server Pages (ASP), or Visual C++ (VC++) and Internet Server API (ISAPI).
By doing some research, you can learn how different factors affect performance. For example, in 1999, Doculabs measured the performance of a Web server benchmark application for a hypothetical online bookstore called Nile. Developers wrote one version of the application in VB with ASP and another version in VC++ and ISAPI, then tested the applications under NT 4.0 and IIS 4.0 running on 4-way Compaq ProLiant 6400 servers. In 2000, Microsoft ran similar tests on Win2K Advanced Server (AS) and Internet Information Services (IIS) 5.0 running on 8-way Compaq ProLiant 8500 servers. Graph 1 shows results of both sets of tests and illustrates how significantly platform and design decisions can affect performance.
Subsequent Microsoft tests of the NT applications on the newer hardware showed that upgrading to Win2K accounted for approximately 30 percent of these improvements. Microsoft's report about these tests, "Architecture Decisions for Dynamic Web Applications: Performance, Scalability, and Reliability," provides more information and makes useful performance recommendations. To read the report, go to http://msdn.microsoft.com/library/techart/docu2kbench.htm.
Systems administrators also need to provide a framework of development, testing, staging, and production servers to meet the organization's performance goals. Figure 1 shows the layout I recommend. When each server or group of servers performs a specific function, you can tune each server for that function.
The development server is a shared server that the development group uses for application design and creation. Developers typically use this server harshly and install several types of software on it. I recommend running a source code control application (e.g., Microsoft Visual SourceSafe) on the development server and linking it to the source code control database.
Using separate servers for development and testing is a best practice to which both systems administrators and developers need to commit. Test servers should be as similar as possible to production servers. Developers use test servers at two stages of the development cycle. Early in the cycle, developers can test prototype applications to determine how their technology choices will perform in production—for example, how an interface that uses VB to build ActiveX documents performs compared with an interface that uses HTML. Ensure that developers test prototypes against a database that represents the types and amounts of data with which the application will work in production. After testing design choices, developers can return to the development server to work out details, confident that the product will perform well.
After the design details come together in a working application, developers should again move the application to the test server. If developers or testers discover a problem with the application during more thorough testing, they can send the application back to the development server and fix the problem there.
The staging server functions as the broker for applications that have been tested and are ready to deploy. Why use a staging server at all? By letting you move an application out of testing without sending it straight into production, the staging server lets you update applications incrementally without hindering the test schedule.
The production server is the final piece in the server layout. Use your production Web server for production only. Don't bog down this server with database, document-management, or other applications. If you want optimum IIS performance, you need to tune your production server specifically for IIS applications.
Storage and Performance
Many Web applications store files on a shared hard disk or server. IIS machines link to this hard disk or server over the LAN. If your application needs to run especially fast, copy the application's shared files to the Web servers' local drive so that the Web servers can access the files through the system's bus and hard disks. Use a fast hard disk, and don't let it get more than about half full—disks slow down as they fill up. To improve performance, defragment the hard disks often. You can also use Storage Area Network (SAN) devices with fibre channel connections for high-performance storage.
The database servers that your Web applications use require particular hardware, and the database server's physical configuration is important. Use separate data sources (e.g., multiple disk controllers, each with its own RAID system) for application data and logs. Separate controllers provide separate data paths to each hard disk system. Database servers also benefit from multiple CPUs and typically require more memory than Web servers. If you're clustering your database servers, make sure you use high-performance fibre channel connections to the shared disk.
Network Load Balancing
High-performance systems should use some sort of network load balancing. Microsoft tested Win2K's Network Load Balancing (NLB) service with the Nile application. The tests showed that combining two Web servers in a load-balanced server farm increases maximum throughput almost 100 percent over the performance of one server. This improvement far exceeds what you can achieve by adding a second processor to a single server. A Web server farm is also more reliable than a multiprocessor system: If one server in the farm goes down, you still have the second server.
Simply having the hardware or software capabilities for load balancing doesn't guarantee that you'll reap the benefits. Developers need to design applications to support load balancing. You can't load-balance an application that requires users to visit the same Web server with each successive request.
Process Isolation
IIS lets you run applications in an isolated memory process to improve IIS's stability. However, applications incur a high performance penalty for running in process isolation mode (although Win2K handles isolated processes better than NT). How you determine whether an application uses isolated processes depends on whether the application uses COM+ components. For applications that use COM+ components, go to Internet Service Manager (ISM) and open Default Web Site Properties. Select Home Directory, and make sure the Application Protection setting is Low (IIS Process), as Figure 2 shows. The Low setting runs all processes in the IIS process space and provides the best performance. The drawback to this setting is that a component crash might take down IIS.
If Application Protection is set to Medium or High and you want to change it to Low, you also need to change the application's Activation type setting. Open Component Services Explorer, right-click the application you want to change, select Properties, and click the Activation tab. Server application is the default Activation type setting. Selecting Library application, as Figure 3, page 66, shows, makes the application run in-process and displays a message box informing you that you need to reset application properties. However, the message doesn't tell you which properties you need to reset, so you need to check all application settings for changes.
After you make these changes, the COM+ application will run in the process space of any application that executes a method within the component. For example, if an ASP script executes a method, the object that contains that method will load in the InetInfo process space. For more information about process isolation and other factors in IIS performance, see "IIS 5.0 Opens the Throttle," Winter 2000.
COM+ Configurations
COM+ and IIS 5.0 are closely integrated, and each COM component that your IIS 5.0 ASP application uses adds overhead and slows the application's performance. Developers and systems administrators need to work together to analyze each COM+ application and tune COM+ features to match the Web application's needs. For example, COM+ offers transaction support that developers can use to automate transaction handling; however, you should tune this feature thoughtfully. Use transactions only when you need them. Also, drill down in Component Services Explorer to the correct COM+ application to turn off features you don't need. For example, events and statistics, synchronization, transactions, and just-in-time (JIT) activation aren't necessary if the components don't use transactions.
Determining whether an application uses COM+ is difficult without digging through the registry. Search the ASP script for the string Server.CreateObject, and ask developers about the application's use of COM components. Be aware that ASP, VB, and VC++ applications can use components from more than one COM+ application.
ASP Configurations
Systems administrators should make certain configuration changes only after checking with developers. Changes to an ASP application might improve performance, but changes made in ignorance of design might break the application.
ASP applications use session variables to store information and send cookies to users' browsers to enable user-specific processing. Because session variables significantly slow an ASP application's performance, you should consider disabling them. However, you can't disable session variables unless the developers have designed the application to run without them. Developers can take many approaches to managing user-state information. I recommend the less-is-more approach: Storing fewer session variables improves performance. In this approach, developers usually store session data in the database, and the Web application maintains only the key to that data.
Buffering is an ASP feature that reduces the number of output commands IIS sends to the output stream and improves IIS performance. When an ASP application has buffering turned on, ASP completely builds each page before sending it. IIS 5.0 turns on buffering by default, and IIS 4.0 turns it off by default.
Developers often turn off buffering to improve application testing and debugging. Ask developers whether they've turned off buffering in the code. If the answer is yes, ask whether buffering is off for programmatic reasons or because the developers turned off buffering for testing and forgot to turn it back on.
After you clear the change with the developers, turn on buffering. Open the Web Site Properties page in ISM, select Home Directory or Directory (for a virtual directory), and click Configuration to open the Application Configuration pages. Click the App Options tab, and select Enable buffering. Although turning on buffering typically doesn't affect the application's functioning, test the application after you make the change.
Developers might have also turned on ASP's debugging settings during application testing. When these settings are on, they dramatically slow down an application. To check the debugging settings, open the Application Configuration pages as you did to turn on buffering. Open the App Debugging page, and make sure that both check boxes in the Debugging Flags section are cleared. For more recommendations about configuring IIS to maximize performance, see "Tweaking NT and IIS for ASP Applications," March 2000.
Security
Win2K and NT's auditing system is a valuable security feature. However, one way to guarantee that your system will run slower than necessary is to overuse auditing. I've seen this mistake bring down many servers. Your security plan should incorporate practical and realistic auditing rules. Don't audit every action on every object on your Web server. Remember that the more auditing you enable, the more nonproduction work the server must do.
COM+ also adds a layer of application-level security. Developers can even weave COM+ security into components. However, the more an application uses COM+ security, the slower the application runs. Most applications add security in the ASP code, the database, or both and don't use COM+ security. If an application's security is sufficient without COM+ security features, open Component Services and turn off the application's security features.
Ongoing Testing and Tuning
Quality hardware, informed configuration decisions, and intelligent design contribute to maximizing Web site performance. But maintaining a high-performance Web site calls for ongoing testing and tuning.
Implement procedures to continue to tune your application and server after the application goes into production. Be sure to apply realistic test loads to the application; tools such as the Microsoft Web Application Stress tool and other third-party tools can help you do so. During testing, note bottleneck points and recruit developers to tweak the code and take performance to a higher level. Then, retest. Document each change and its results. Rigorous testing and tuning will show you how each change you make—whether in design, hardware, or configuration—affects performance. That knowledge is the key to maintaining maximum IIS performance.
From design through maintenance, building and keeping high-performance Web applications requires a team approach. Collaborative and goal-oriented coding, testing, configuring, and tweaking will produce an application and Web server environment that meets your performance requirements.
