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.