Tweaking NT and IIS for ASP Applications

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.

Session state support lets developers track user information in an application. Session state support works by sending cookies to users' browsers. Each time a user visits a page in an application, ASP can retrieve the cookie and look up the user's state information. When session state support is on, the Session_OnStart event in the Global.asa occurs the first time a user visits the application. When the session ends, the Session_OnEnd event occurs. These events provide hooks that developers can use to trigger user-specific processing in the application.

When an application that is using session state support starts, the system creates a session object, which increases the server's overhead. When more users use the application, overhead increases to support session state management. Developers also use session variables to store various types of information. The more data a developer stores in session variables, the more memory the variables use.

When you turn off session state support, you not only decrease server overhead but also improve the performance of pages with multiple objects such as frames and certain browsers. Microsoft Internet Explorer (IE) 5.0 and IE 4.0 both use separate threads to process pages in a frameset. When you disable session state support, users experience better performance because IE processes the pages simultaneously, thus rendering Web pages faster. When you enable session state support, IIS turns off this multithread processing and each page in the frameset processes sequentially on the server. Thus, page-frame processing slows down.

Session state support also doesn't work in some load-balancing situations. You usually access IIS servers through a load-balancing system such as the Microsoft Windows Load Balancing Server (WLBS). If the load-balancing system uses simple round-robin load balancing, users bounce from one server to another when they navigate an application with the browser. If a user starts an application on one server and the load-balancing system reroutes the user to another server midway through the session, the session variables on the first server won't transfer to the second server. As a result, the application won't work correctly. Some schedulers or load-balancing systems handle session state by directing users to the same server each time the users return to the application during a session.

Conserving application resources. Conserving application resources is one of the easiest ways you can improve NT Server and IIS performance. One simple step is to use only the file extensions that an application needs. You can add and remove file extensions on the App Mappings tab of the Application Configuration property sheet, which Screen 4 shows. When you remove all mappings except those an application uses, you reduce the overhead that IIS needs to process requests for pages. For example, if your server isn't running any Internet Database Connector (IDC) applications, you can remove the .idc entry. If your application doesn't use .shtml or .shtm files for include files, you can remove those entries.

Examine your script engine cache to further conserve resources. You can control the maximum number of script engines that IIS will cache at one time. When you increase this number, you let IIS use more server memory as the script engine cache and you'll get better system performance. To change the script engine cache parameter, open the master properties for the server. Right-click the server name in the ISM, then select Properties. The Edit button is to the right of the WWW Service entry in the list. Select WWW Service, then click Edit. Next, select the Home Directory tab, then click Configuration. Configuration options for ASP applications will appear. Select the Process Options tab to see the Script Engines Cached setting. The default setting is 30.

The Active Server Pages: Script Engines Cached Performance Monitor counter shows the current number of cached script engines. If the value shows the maximum number of script engines, you can change the setting to let IIS cache more script engines. Don't set the value to 250 or more because returns diminish at high settings. After you change the value, apply your changes and retest with Performance Monitor.

You can also control the number of ASP pages that IIS caches. Reducing the number of cached pages can make more memory available for other tasks. Max ASP Files Cached defaults to Cache all requested files, which caches all ASP files. To control the number of cached pages, change the setting from the default to a number that is 25 percent of the total ASP pages in your application. For example, if your application has 100 ASP pages, set the value to 25. (Microsoft details this suggestion in its article "Enhancing Performance in Internet Information Server 4.0" at http://support.microsoft.com/support/kb/ articles/q235/4/61.asp.) As always, test production server changes before you implement them.

Tweaking IIS Settings
To affect IIS performance, you can change several settings in the NT Registry and the IIS metabase. These settings can affect performance either positively or negatively. The only way you'll know whether changing these settings has improved the performance of your server is by monitoring server performance. Change only one parameter at a time so that you know how the server performs after each change and whether your application is performing optimally.

Microsoft created the Web Application Stress simulation tool for testing IIS applications. You can find the tool at http://homer.rte.microsoft.com. This tool lets you create a script and run it against your applications. The script runs in multiple threads on each client that runs the test to simulate various loads on the server. You can use as many client machines as you need to apply the load. For information about other application management tools, see my article in the IIS Administrator newsletter, "IIS Resource Kit Utilities," October 1999.

Several settings that you can change affect IIS performance. After you have a stable application and have established performance criteria, you can tweak these settings. Changing settings without a reason to change them won't benefit your system's performance and might cause problems.

One setting you need to examine is the ProcessorThreadMax Registry parameter, which determines the number of threads that IIS uses to process applications. The default setting is 10, which means that 10 ASP worker threads per processor exist. IIS automatically uses only the number of threads it needs. If the demand goes up, the number of threads goes up until the number is at the maximum. However, you can monitor the server and determine whether changing this value will improve your system's performance. The Active Server Pages: Requests Queued performance monitor counter tracks the number of ASP requests in the queue. This value is usually 0. If the value begins to increase, you might be able to shorten the queue by setting the ProcessorThreadMax parameter to a higher value. The parameter doesn't exist by default, but you can add it under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesW3svcAspParameters Registry key. After you change ProcessorThreadMax, you'll see the processor utilization on the server increase and the requests queued should decrease. You also need to check the RequestQueueMax parameter. If your server is generating too many Server Too Busy errors, you can lengthen the queue by increasing the RequestQueueMax value.

Other Registry parameters can affect performance, and it's often worth the time to find out whether Registry changes can improve your system. Chapter 4 in the Microsoft Internet Information Server Resource Kit is an excellent resource for monitoring and tuning. To explore other possible Registry parameter tweaks, take a look at the following articles on the Microsoft Developer Network (MSDN) and Microsoft Web sites:

Further Exploration
The FM Stocks application, which is available on the Microsoft Scalability Center site at http://msdn.microsoft.com/vstudio/centers/scale/tuning.asp, provides tremendous Web application tuning information. The Microsoft Scalability Center also provides information about building and running high-performance applications. Visit the site frequently to catch new tips.

The Microsoft Web Application Stress simulation tool, which I describe above, is also a great way to test your applications. You can use it to assess the effects of all the changes I suggest in this article and to fine-tune your applications, NT Server, IIS, and the SQL Server database. Using this tool will provide you with valid test data not only about your applications but about the servers and other technologies in your system.

Finally, remember that you don't build and run applications in a vacuum. Tuning NT and IIS is only one part of the equation. Build your applications using proper techniques and proven methods, design and integrate databases with a properly configured server, and work with your entire team to ensure the top performance of all your applications.