Small changes can add up to big performance improvements
Active Server Pages (ASP) is running in many businesses from the Internet to corporate intranets, and systems administrators are choosing Windows NT Server and Microsoft Internet Information Server (IIS) to run ASP. However, as a systems administrator you must tune NT Server and IIS efficiently to maintain the best possible performance. You can set yourself up for success by configuring NT Server to make it an effective platform for IIS. In addition you can implement some simple but crucial changes to IIS configuration and tweak IIS to help your servers perform optimally.
Remember that as you make these changes, you must test your applications and tweak your server's environment accordingly. Keep a checklist of settings for your servers so that you can be sure you've configured each server correctly. Automate as much of your server setup as you can to configure servers quickly and correctly. If all your servers have the same hardware configuration, consider using Norton Ghost or a similar automatic replication utility to set up new servers. If you use a utility to replicate servers, verify that the utility lets you create a new SID for each server. Also, test the replication process on only one system before you build several new servers. You don't want to copy a system that has errors in application settings. You might also encounter problems with the IIS metabase and replicated systems if the SID changes. If such problems occur, you might need to reinstall IIS on the problem machine.
Start with NT Server Configuration
To set up NT as an effective platform for IIS, you must configure NT correctly as an application server. To do so, first consider the type of server you intend to use. Then, consider factors that can improve server performance. For example, Figure 1, page 104, shows a typical Web server setup. The five Web servers run IIS and Microsoft Transaction Server (MTS). No other applications, such as Microsoft SQL Server or Microsoft Systems Management Server (SMS), run on the Web servers. However, the Web servers might run COM components as part of IIS or MTS. When you run only IIS and MTS and their components on your Web servers, you can optimize the servers for IIS. To do so, install as much memory as possible on the servers. IIS uses memory for processing and for the cache, including the ASP cache, which stores compiled ASP files. With more memory in the server, IIS can effectively use all of its operations, including the cache.
Another way to improve server performance is to use the fastest processors you can and add multiple processors to the IIS server. Faster processors execute ASP code faster, and multiple processors spread the threads that process the application among the processors. However, I suggest you start with one processor in a multiprocessor system and add processors as you need them. If you have more processors than you need, performance can degrade.
A third way to boost server performance is to configure disk systems to perform optimally for your application. In his article "Tuning NT Server Disk Subsystems," March 1999, Curt Aubley showed that RAID 0 (striping) is the fastest form of RAID disk access possible in all situations because RAID 0 optimizes reading and writing without incurring the overhead that other forms of RAID do. RAID 5 (striping with parity) reads as fast as RAID 0 but writes much more slowly. The IIS servers in Figure 1 aren't data repositories and don't typically require fault tolerance for updates, as SQL servers do. Thus, you could use either RAID 0 or RAID 5 for these servers and optimize the data-reading performance. RAID 0 is my favorite choice for IIS servers because it increases access speed faster, even when you're installing new software on the server. You don't need to protect your software installation with RAID 5, and RAID 5 will only slow down the installation.
Identify services or other applications that you aren't using, and turn them off or disable them. You can use Task Manager to find applications or processes that are running; then, you can investigate each one to discover whether you need it. After you decide which services to disable, enter the information about each service on your server setup checklist.
Finally, configure NT as an application server. Such a configuration involves two settings that control how NT processes applications and uses memory. The first setting lets NT manage memory from an application perspective instead of a file-server perspective. Open the Control Panel Network applet, and click Services. Then, right-click the Server service. In the resulting Server dialog box, select Maximize Throughput for Network Applications, as Screen 1 shows. If you don't make this selection, NT can page part of the IIS working set to disk, which will slow down your server's request handling. I recently implemented this change on a client's server, and response time immediately decreased.
The second setting changes the way NT processes requests from background processes (e.g., IIS) and foreground processes (e.g., Microsoft Word). This change ensures that NT doesn't boost the priority of any foreground (i.e., desktop) application to the detriment of IIS and other background applications. If you don't boost foreground processes, applications such as NT Event Viewer and Performance Monitor will still run, but they won't have priority over background processes. If you manage servers remotely with a package such as Symantec's pcANYWHERE, you can still work with foreground applications, but NT won't let you work faster if doing so sacrifices your server applications' performance. Open the Control Panel System applet, then open the Performance tab, which Screen 2 shows. Drag the slider to None on the left side of the screen, and click OK.
IIS Configuration
To improve performance, you can tweak many IIS and IIS-related settings. You must take only the steps that are appropriate for your system, but you can improve your system's performance if you turn on application buffering, turn off debugging, don't set applications to run in isolation, and encourage developers to work separately. In addition, you can turn off session support and conserve application resources by tweaking your script engine cache and ASP cache. Some of these changes, such as changing the buffering setting, work only with ASP applications. If you have a static Web site, you can't use buffering or other settings that affect ASP applications.
You can improve your system's performance by turning on application buffering. When buffering is on, IIS processes each Web page completely before transmitting data. When buffering is off (the IIS 4.0 default setting), IIS outputs pages as soon as you generate HTML. Therefore, when a developer places HTML tags in a page or uses Response.Write to generate output, the output immediately slows because IIS processes the page one line at a time. In addition, because the browser won't accept changes after it receives an HTML header, developers can't perform any operations that affect HTTP headers, such as using Response.Redirect.
To turn on buffering, set the Enable buffering property in the Internet Service Manager (ISM). Open the ISM, and locate the folder you want to change. Right-click the folder, and select Properties from the shortcut menu. Click Configuration, then select the App Options tab, which Screen 3 shows. Select Enable buffering, and click OK. Developers won't need to modify the application or make any other changes unless they want to change the application's appearance. Pages will process completely, so when developers work on pages that contain a large amount of processing, they can periodically use the Flush method to force output into the HTML stream.
ASP debugging is handy for tracing errors in applications but can degrade performance. The Enable ASP server-side script debugging setting on the App Debugging tab of the Application Configuration properties page controls ASP debugging. Developers can enable this setting, then debug the ASP code with Microsoft Visual InterDev. When you enable debugging, the ISM makes the application an out-of-process application. An out-of-process application runs in its own memory space, which causes IIS to process data into a standard form before sending it to the application. This sequence of events will slow down the application. Out-of-process applications can also cause IIS to eventually crash. Be aware that Visual InterDev can dynamically change the debugging setting and return the setting to its default state during a debug session. If Visual InterDev crashes during the debug cycle, the setting can remain enabled.
Preliminary documentation for Windows 2000 Web Services (formerly IIS 5.0), which you can find at http://msdn.microsoft.com/library/ psdk/iisref/apro64br.htm, points out another downside of the ASP debugging setting: When you turn on ASP debugging in Windows 2000 Web Services, debugging serializes on all IIS application threads and affects the performance of all applications on the server. I suspect this problem also exists in IIS 4.0.
Turn off ASP debugging for all applications on your production server. You can set up the server to use debugging, but don't enable debugging for applications. Then your developers can troubleshoot problems in production applications when necessary, but the server won't exhibit a performance drain in typical use.
Don't set applications to run as out-of-process applications. Out-of-process applications run in their own memory space, significantly degrading performance, and can cause IIS to crash.
Finally, encourage developers to use a combination of developer servers and their own workstations when building applications. Developers can use their own workstations (with NT Workstation or NT Server, IIS, and Visual InterDev) to create and enhance Web applications. Then, the developers can copy the applications to a development server, where others can access the applications. The personal workstation approach lets developers work on and debug their applications without affecting other developers or production users. Thus, developers are free to implement and test changes on their local workstations without affecting the server load.
Turn off session state support. Turning off session state support is another change you can make in the Internet Service Manager Properties page that will reduce system overhead. Change session state support only with the knowledge of your development staff and after you determine whether your applications use the support. Web masters can't independently disable session state support because application developers might rely on the support for their applications. Before you disable session state support, make sure application developers remove the Session_OnStart and Session_OnEnd event code from Global.asa and remove any use of session variables from their applications. Then, you can clear the Enable session state check box, which Screen 3, page 105, shows.