Server Reliability Through Process Isolation
From Mynoteswiki.com
J.D. Meier
November 22, 1999
Contents |
Introduction
Web-server reliability continues to be a goal shared by Active Server Pages (ASP) developers and system administrators alike. Let's face it: When it comes to running ASP applications on your server, few things are worse than having an ASP application go south and take your server down with it. Problems, ranging from poor code to unexpected run-time issues, can compromise your server's availability.
In desktop applications, risks are minimized, because normally one application runs under a given process. If that process should happen to choke, only that application is affected. However, under Internet Information Server (IIS), typically several applications are sharing the same process space, so one rogue application can jeopardize your entire server's health.
Fortunately, there is a solution, and it's been available to you for some time. Process isolation, which was introduced with IIS 4.0, allows you to protect your main IIS process. While it does not take the place of robust error handling, it does provide an additional layer of durability for your Web server.
Despite the fact that this feature has been available for a while, isolation is still often treated as a black box. In this article, I'll offer a look at how process isolation in IIS works. I'll also touch upon some changes introduced with IIS 5.0, and explain how Microsoft Transaction Server (MTS) comes into the picture. By the end of the article, you should be able to not only configure your Web application to run in a separate memory space, but you will also understand how this impacts your application.
Isolating Your Process
Before I explain how isolation works, let's get some hands-on experience by marking a Web-based application to run out-of-process. Either create a new Web application for testing purposes or use an existing Web app on which you can test settings. You can configure your Web application to run in an isolated process using the Internet Service Manager (ISM). The ISM is accessible via the Windows NT Option Pack program group. After launching the ISM, follow these steps to run your Web app in an isolated process: 1. Click your Web application from the left-hand pane of the ISM. 2. Click Properties from the context menu. 3. If the Create button is enabled when your Web application properties appear, as in Figure 1 below, then you need to click the Create button. This will mark the application as an application root. Your Create button will then morph into a Remove button, which can be used to unmark your application as an application root.
Figure 1. Create button is enabled
4. Click the Run in separate memory space checkbox. See Figure 2.
Figure 2. Run in separate memory space
5. Click the Apply button. You've just isolated your Web application process from IIS! There are a few notes worth mentioning about the preceding steps. In Step 3, when we clicked the Create button, this added an entry for our application into the metabase. The metabase, introduced in IIS 4.0, holds configuration parameters for IIS and is faster and more flexible than the registry. For more information on the metabase, refer to either the NT Option Pack documentation or the Knowledge Base (KB) article, Q240225 Description of Adsutil and MetaEdit Utilities Used to Modify the Metabase .
While there are a number of ways to inspect the metabase, I use a utility called adsutil.vbs, which I got when I chose to install Windows Script Host during my NT Option Pack installation. More information on the Windows Script Host is available at http://msdn.microsoft.com/scripting/ .
From a command prompt, I can issue the following command:
adsutil.vbs enum /w3svc/1/root/servinitup
to dump the application properties of my application root to the console window.
As you can see in Figure 3, AppIsolated is currently set to True. This is because I clicked Run in a separate memory space back in Step 4. Notice AppPackageName and AppPackageID. These entries would not be here if the Web application were set to run in-process in IIS.
Figure 3. Metabase entry for my ServinItUp application root
If you take a quick look at your MTS package, created in Step 4. through the ISM, you will see a new MTS package (MTS information is located below the IIS information). See Figure 4.
Figure 4. Our new MTS package
MTS Package Identity
Right-click your new MTS package, and click Properties. Switch to the Identity tab to view the account used for your package identity. The Identity tab is extremely important when it comes to isolating your Web application, and there are a few pitfalls you need to know.
Figure 5. MTS package identity
Now you need to choose either the Interactive User or a specific account. The default depends on the options you chose during your NT Option Pack installation.
If you run your package as the Interactive User, you may encounter problems when a limited user is logged on to the machine, or when nobody is logged on to the machine (which is usually the case for a production machine). Common symptoms include:
- ASP files calling COM components return CreateObject errors when there’s nobody logged on to the box. See the following KB article for more information: Q241057 PRB: Server Execution Failed when calling MTS COM Component from ASP .
- Projects created in Visual InterDev are not marked as application roots on the server when nobody is logged on to the box. Consequently, Global.asa won’t fire. See the following KB article for more information: Q188715 Global ASA Not Firing when Visual InterDev made IIS 4.0 Application .
Typically, I don't recommend relying on the Interactive User, since the run-time behavior of the application will vary depending on who logs on to the Web server.
The IWAM_<machine> (IWAM for short) account, seen in Figure 5, can be a common source of problems if you don’t know a few tricks. The IWAM account is an important account; it's the default account that's used when you set your Web applications to run out of process from IIS.
A problem occurs when you change the IWAM account’s password through NT USERMGR without informing IIS of the changes. You need to update IIS manually because the IWAM account does not have the same password synchronization option that the IUSR account does. IUSR’s password synchronization option automatically synchronizes any changes in USRMGR with the IUSR's password stored in the metabase. If you change the password to the IWAM account in USERMGR, you will also need to make the same change to the MTS packages for out-of-process applications that you have already created for IIS. You also need to make the change to the WAMUserPass property in the metabase, which is where IIS stores the IWAM account information that it will use when it is creating new out-of-process applications in the future.
If you don't synchronize the IWAM password in the metabase manually, you will have problems creating MTS Server packages. Unfortunately, your primary symptom is not very helpful unless you know what it means. If you see a "Y" for the identity of a Server package, then your IWAM account is out of sync. See the following KB article for more information: Q195956 Cannot Set AppRoot OutProc, MTS Package Identity Set to "Y" .
Behind the Scenes of Isolation
What exactly happens now that you've isolated your Web application? In a nutshell, your Web application will be loaded into a new instance of MTX.EXE (the MTS runtime). If you bring up Windows Task Manager and view Processes, you’ll most likely see at least one instance of MTX.EXE.
There is one instance of MTX.EXE hosting your in-process Web applications, and a separate instance for each of your isolated Web applications. However, the other instances of MTX.EXE will not be loaded until requests are made to your Web application. Along with your new instance of MTX.EXE comes an additional thread pool for your Web application. The ASP thread pool is managed by MTS, and has by default 10 threads per processor. Each additional out-of-process Web application will get its own ASP thread pool. Do not confuse this thread pool with IIS's main thread pool, which is used for I/O.
If you are a component developer, you get another bonus. Normally, when you try to recompile a DLL that's in use by IIS, you will get a Permission Denied error message. Unfortunately, the workaround requires stopping and restarting the Web service. However, when your Web application is isolated, you can simply unload it through the ISM so that you can recompile your DLL. To unload your parent MTX.EXE process for your Web application, bring up your Web application's properties through the ISM and click the Unload button.
All of this sounds great. So, what are the caveats? Whenever you make cross-process calls, you can see a performance hit because of marshaling. You can minimize performance penalties by passing parameters by value. You can also take advantage of early binding. Together, these techniques can significantly reduce round trips across processes, leading to better performance. You also need to be aware that your process identity for your Web application is determined by the Identity setting of your Web application's MTS package -- by default, this is the IWAM_<machine> account. Keep this in mind when you suspect that security context is related to a problem you are facing.
Changes in IIS 5.0
Currently, as of IIS 5.0 running on Win2000 Beta RC3, there are some changes regarding application isolation. I'll run through some of the more significant changes. You can read much more about the changes through the documentation when Windows 2000 final release ships.
The most obvious and talked-about change is that MTS morphs into COM+. This effectively brings together MTS, COM, and DCOM under one umbrella. You will notice that instead of working with MTX.EXE, you will be working with Dllhost.EXE.
As far as the thread pool is concerned, the default number of threads is bumped up to 25. Instead of 10 threads per processor managed by MTS, you have 25 threads per processor managed by COM+. This rule applies to each out-of-process Web application. Run in separate memory space gets a face-lift. You now have the concept of pooled processes. Essentially, you end up with a choice between three possibilities for your isolation level: 1. Low (IIS Process) 2. Medium (Pooled) 3. High (Isolated)
Low means that the Web application is executing in Inetinfo.exe. Medium offers you the ability to share an instance of Dllhost.EXE between multiple out-of-process Web applications. High means that you get an instance of Dllhost.exe dedicated to your Web application. You can equate this to the IIS 4.0 Run in separate memory space option, but the performance hit of going out-of-process is much reduced in IIS 5.0. Couple this with overall improvements in ASP performance means that out-of-process performance is better than IIS 4.0 in-process performance.
Conclusion
Server stability doesn't have to be beyond your reach when you are running ASP applications on your server. As you have seen, isolation does come with its challenges. However, now that you know more about how isolation works, you have the know-how to work through these challenges. For additional information, see the following Webcasts: Windows DNA from Design to Deployment - How to Avoid Critical Problems and Solving Problems in Windows DNA Solutions . In the end, the fortification of your server will more than pay you back for the time you spent figuring out what isolation is all about.
J.D. Meier was born and reared on the U.S. East Coast. Since heeding Horace Greeley's advice, he has worked as a Developer Support engineer specializing in server-side components and Windows DNA applications involving MTS and ASP technology.
