Performance improvements make your applications cruise

Faster performance is a key feature of Microsoft IIS 5.0. To kick IIS into high gear, Microsoft has improved many of IIS's core components, such as the Active Server Pages (ASP) engine. The company also has set IIS 5.0's default performance values at fast, realistic numbers. To make IIS run as fast as possible on your systems, you need to make only a few changes in IIS and Windows 2000 settings.

IIS 5.0's ASP engine is dramatically faster than the ASP engine in IIS 4.0. Microsoft's internal testing shows that applications containing only ASP code can run up to twice as fast on IIS 5.0 as they can on IIS 4.0. This speed improvement means that an ASP application running on IIS 5.0 can support up to twice as many users while delivering the same performance that the application does when it runs on IIS 4.0. If you run IIS 5.0, the difference you'll see in application performance will vary depending on your system's configuration (e.g., number of CPUs, memory size, network configuration).

Much of IIS 5.0's improved performance is due to Win2K's efficiency in using multiple processors. Applications that run on Win2K multiprocessor systems are much faster than applications that run on Windows NT 4.0 multiprocessor systems. Efficient handling of multiple processors improves your ASP application performance, making it easy for you to scale up an application's performance by adding processors. Performance-testing of applications (such as Vertigo Software's Fitch & Mather Stocks 2000—FMStocks 2000) that rigorously tests scalability and performance demonstrates that Win2K performance beats NT 4.0's performance. Because IIS 5.0 runs on top of Win2K, Win2K's performance improvements as an application server also speed IIS 5.0.

Other features, such as IIS 5.0's Application Protection and component handling and Win2K's file sharing, also affect IIS 5.0 performance. Let's look at these features and at some specific IIS 5.0 settings with an eye toward maximizing performance.

Application Protection
IIS 5.0's Application Protection lets you run applications in an isolated memory process. This feature can increase stability by keeping application processing isolated from IIS.

The three options for IIS 5.0 Application Protection are Low (IIS Process), Medium (Pooled), and High (Isolated). You can change the Application Protection setting on the Home Directory tab of a Web site's Properties page, as Figure 1 shows, or on the Virtual Directory Properties page. (To reach either Properties page, open Internet Services Manager—ISM, right-click the Web site or the Virtual Directory that you want to change, then select Properties.) An ASP application in the Low (IIS Process) protection mode runs in the same process space (i.e., inetinfo.exe) that IIS does. If the application crashes and causes a memory violation of the IIS process or a catastrophic failure of another critical server process, IIS and all other Web applications can crash as well.

When you use the Medium (Pooled) Application Protection setting, your application runs with all other pooled applications in the dllhost.exe process. Like applications in the Low (IIS Process) protection mode, if one of the applications that uses the Medium (Pooled) protection mode crashes, it can cause all applications that run in the same process space to crash.

The High (Isolated) protection setting in IIS 5.0 is similar to IIS 4.0's Run in separate memory space setting. When you use IIS 4.0's setting for an ASP application, the application moves to a separate Microsoft Transaction Server (MTS) package. The application's shift to MTS increases stability by separating the application process from IIS, but the application's performance slows considerably because of the overhead involved in marshaling the MTS out-of-process package.

The Application Protection settings in IIS 5.0 operate differently from IIS 4.0's protection setting, however. When you mark an ASP application as High (Isolated) in IIS 5.0, ISM creates a new COM+ application and moves the ASP application into it. (In Component Services Explorer, the new application name will look something like IIS-\{Default Web Site//Root/DNATestProject1KLS\}; the last part of the name—DNATestProject1KLS—is the application name.) Each high-protection application runs in a separate copy of dllhost.exe, so if the application crashes, it's unlikely to cause other applications to crash.

Applications that run under the Medium (Pooled) or High (Isolated) protection setting in IIS 5.0 show a dramatic performance improvement over the way the same applications perform in IIS 4.0, according to the Microsoft Developer Network (MSDN) article "Leveraging ASP in IIS 5.0" (http://msdn.microsoft.com/workshop/server/asp/server02282000.asp). Author J. D. Meier points out that using IIS 5.0's Medium (Pooled) protection setting typically results in better performance than running an in-process application in IIS 4.0. This improvement means that with IIS 5.0's Medium (Pooled) protection setting, you can move your application to a somewhat isolated environment and still get good performance. Even in the High (Isolated) protection setting, an application will perform better than it would if it were running in process in IIS 4.0.

Components
IIS 5.0's handling of components also improves performance compared with IIS 4.0. A good programming practice that all IIS 5.0 developers need to use with components is to let the ASP engine release an object when the application no longer needs the object. Releasing unneeded objects frees valuable resources.

IIS 4.0 doesn't release objects until the page containing the object reference goes out of scope. For a long-running page, delaying the object release can add significant overhead to the application. Slower performance is a result because the page doesn't complete execution until all objects are completed and the ASP code in the page has finished running.

The performance benefits of promptly releasing an unneeded object are especially apparent when many users simultaneously hit your application. When such a situation occurs in IIS 4.0, each page ties up an object and keeps the object in memory until the page is completed, using resources unnecessarily in the meantime and thereby slowing performance.

You can use VBScript code to release an object. For example,

Set oCust = Nothing

sets the oCust variable, which contains a reference to an object, to the keyword Nothing, which removes the reference. This code causes the ASP engine to immediately release the object that oCust points to.

More Settings
The IIS 5.0 metabase contains the ASPProcessorThreadMax setting, which in IIS 4.0 is called ProcessorThreadMax and resides in the Registry. Microsoft changed the default value for this setting from 10 in IIS 4.0 to 25 in IIS 5.0. This change can improve performance by letting more threads handle the ASP process. If your system has enough processors and your system's CPU is speedy enough to use more threads, the new setting will make the ASP process more efficient. If you use IIS 5.0, you won't need to adjust this setting unless system tests show that the default setting creates a bottleneck.

If you installed Indexing Service on your server, you might be able to improve performance by using ISM to turn off the Index this resource option. If your application generates HTML from a database or other source and doesn't use static HTML files that users must search, you can try turning off the Index this resource option because you probably don't need Indexing Service to index the files. Turning off this option reduces the overhead that the server uses for the ASP application and can slightly improve performance.

You can use the Performance tab of the Web site Properties page to adjust the memory that IIS 5.0 uses to handle the Web site's connections and resources. IIS documentation says you need to set the Performance Tuning slider slightly higher than the number of hits per day that you anticipate the Web site will receive. You can change the hits-per-day setting by moving the slider to the appropriate number of hits (i.e., fewer than 10,000, fewer than 100,000, more than 100,000). Moving the slider to a higher number makes more memory available to handle Web site resources.

The Enable process throttling option, a new option on IIS 5.0's Performance tab, causes IIS to limit the amount of CPU time the ASP engine can consume for applications that you've set for High (Isolated) protection. When you enable this option, a high-protection application by default can use no more than 10 percent of the CPU time in a 24-hour period. If an application exceeds this limit, IIS writes an entry to the event log. You can activate the Enforce limits option to cause IIS to take a more drastic action, such as stopping all out-of-process applications, when an application exceeds the limit. If you plan to use process throttling, read the IIS documentation for more information.

Security presents a performance trade-off in IIS 5.0. Activating security settings in IIS or Win2K enables features that IIS or Win2K must monitor or act on. Security adds a layer of overhead to every task it affects. If you don't need more than anonymous security, don't enable other types of security, such as Secure Sockets Layer (SSL).

Security shows up in many places. Win2K, IIS, COM+, and SSL all have settings you can manipulate to make your system more or less secure. You need to understand how much security your system requires and how that level of security will affect your system's performance. For example, the test team in a lab where I work found that a particular application that uses Visual Basic (VB) and ASP could serve 250 pages per second. Changing just one security setting in COM+ increased the performance to 950 to 1000 pages per second.

File Sharing
You can use Win2K's File Sharing feature to improve IIS 5.0 performance by changing a File Sharing setting for the network adapter that handles incoming HTTP requests. To make this change, go to the Start, Settings, Network and Dial-up Connections window, which Figure 2 shows. Then, right-click the connection you want to change and select Properties. On the Server Optimization tab, select Maximize data throughput for network applications, as Figure 3 shows, then click OK. This setting optimizes Win2K's memory usage for network applications that perform caching, such as Microsoft SQL Server and IIS. The setting also prevents Win2K from swapping the IIS working set from memory to disk when Win2K memory runs low. Preventing such a swap can dramatically improve performance. On a server that has multiple adapters (i.e., a multihoming server), you can adjust the File Sharing settings for each connection that you use.

The Hardware Factor
Hardware can have a significant effect on IIS 5.0's performance. A team working at a Microsoft lab tested various hardware combinations for IIS Web servers. The team compared IIS performance on sophisticated servers with a lot of memory (512MB), fast disks, and multiple CPUs to IIS performance on servers with smaller amounts of memory (128MB), standard IDE disks, and multiple CPUs. The best-performing Web servers were those that had multiple fast CPUs. Neither the amount of memory, nor the type of disk interface (e.g., SCSI, IDE), nor the processor speed had a major effect on IIS performance. These findings mean that you can achieve dramatic performance gains by adding processors. If you use Network Load Balancing (NLB) or a hardware solution (e.g., a router that provides round-robin DNS switching), you can improve performance by adding more machines.

Test labs and real-world experience with IIS 5.0 implementations on Win2K show that using the default settings and selectively changing only certain parameters will result in the best performance. Don't change the default settings for your system's network interface until you've tested your system's performance and can measure precisely how each change affects performance.