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_MACHINE\SYSTEM\CurrentControlSet\ Services\W3svc\Asp\Parameters 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:
- "Tuning the FMStocks Application" at http://msdn.microsoft.com/vstudio/centers/scale/tuning.asp
- "Microsoft Visual Studio Scalability Center," at http://msdn.microsoft.com/vstudio/centers/scale/default.asp
- "ASP Scripting Optimization" at http://msdn.microsoft.com/library/psdk/iisref/perf9ini.htm
- "Tuning Internet Information Server Performance" at http://www.microsoft.com/isn/whitepapers/tuningiis.asp
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.