ASP Tips Out of Process Execution Trades off Performance for Reliability

ASP Options

ASP Applications can be configured to run in one of three ways. With IIS 5.0, the terminology "isolation level" has been introduced to describe these options. The three isolation level values are Low, Medium, and High:

• Low Isolation. This is supported in all versions of IIS and is the fastest. It runs ASP in Inetinfo.exe, which is the primary IIS process. If the ASP application crashes, so does IIS. (To restart IIS under IIS 4.0, Webmasters would monitor the site using tools such as InetMon, and fire off batch files to restart the server if it failed. IIS 5.0 introduces reliable restart, which automatically restarts a failed server.)
• Medium Isolation. IIS 5.0 introduces this new level, which is referred to as out-of-process, since ASP runs outside of the IIS process. In Medium isolation, all ASP applications configured to run as Medium share a single process space. This reduces the number of processes required to run multiple out-of-process ASP applications on one box. Medium is the default isolation level in IIS 5.0.
• High Isolation. Supported in IIS 4.0 and IIS 5.0, High isolation is also out-of-process. If ASP crashes, the Web server doesn't. The ASP application is automatically restarted on the next ASP request. With High isolation, each ASP application that is configured to run as High runs in its own process space. This protects ASP applications from each other. Its drawback is that it requires a separate process for each ASP application. This can add up to a lot of overhead when dozens of applications need to be hosted on one box.

Which option is the best? In IIS 4.0, there was a fairly steep performance penalty for running out-of-process. In IIS 5.0, a lot of work was done to minimize the cost of running ASP applications out-of-process. In fact, in most tests, ASP out-of-process applications in IIS 5.0 run faster than in-process applications in IIS 4.0. Regardless, in-process (Low isolation level) still produces the best performance on both platforms. However, you won't see much benefit to the Low isolation level if you have a relatively low hit rate or low maximum throughput. Therefore, you should not feel the need to reach for the Low isolation level until you need hundreds or thousands of pages per second per Web server. As always, test with multiple configurations and determine which trade-offs you are willing to make.

Note When you run ASP applications out-of-process (Medium or High isolation), they run in MTS on NT4 and COM+ on Windows 2000. That is, on NT4 they run in Mtx.exe, and on Windows 2000, they run in DllHost.exe. You can see these processes running in Task Manager. You can also see how IIS configures MTS Packages or COM+ Applications for out-of-process ASP applications.

COM Options

COM components also have three configuration options, though not completely analogous to the ASP options. COM components can be:"unconfigured," configured as Library Applications, or configured as Server Applications. Unconfigured means that the component is not registered with COM+. The component will run in the caller's process space, that is, they are "in-process." Library Applications are also in-process, but benefit from COM+'s services, including security, transactions, and context support. Server Applications are configured to run in their own process space.

You may see a slight benefit of unconfigured components over Library Applications. You're likely to see a large performance benefit of Library Applications over Server Applications. This is because Library Applications run in the same process as ASP, whereas Server Applications run in their own process. Inter-process calls are more expensive than in-process calls. Also, when passing data such as recordsets between processes, all of the data must be copied between the two processes.

Pitfall! When using COM Server Applications, if you pass objects between ASP and COM, make sure that the objects implement "marshal-by-value," or MBV. Objects that implement MBV copy themselves from one process to another. This is better than the alternative, in which the object remains in the creator's process, and the other process calls repeatedly into the creating process to use the object. Disconnected ADO recordsets will marshal-by-value; connected recordsets won't. The Scripting.Dictionary does not implement MBV and should not be passed between processes. Finally, a message to VB programmers out there: MBV is NOT achieved by passing a parameter ByVal. MBV is implemented by the original component author.

What to Do?

If we were to recommend configurations with reasonable trade-offs of performance versus reliability, they would be as follows:

• On IIS 4.0, use ASP's Low Isolation level, and use MTS Server Packages.
• On IIS 5.0, use ASP's Medium isolation level, and use COM+ Library Applications.

These are very general guidelines; hosting companies generally run ASP at Medium or High Isolation level, whereas single-purpose Web servers can be run at Low isolation. Measure the trade-offs and decide for yourself which configuration meets your needs.