IIS and the interconnectivity of development, hardware, and configuration
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.
Previous
Register
