Administering an ISP Installation

Running Applications in Isolation

Once you’ve tested your applications and are satisfied with their performance, you’re ready to make them available on the Web. IIS 5.0 allows you to run applications in one of two ways: in process or out of process (in isolation). Process isolation allows multiple Web applications to run on one Web server without crashing, by running each application that is on the server in a separate memory space (out of process).

The advantage of running everything out of process means that if one application fails, it won’t cause the others to fail. The disadvantage is that this adds an extra step when diagnosing problems. Despite the disadvantage, it is recommended that you run an application out of process when you’re not sure of its integrity.

In the IIS 5.0 architecture, all the IIS services run in the Inetinfo process. (You can look at this process by opening the Task Manager and clicking the Process tab.) When you run an application out of process, you will find an associated Mtx.exe process in the Task Manager. (For example, if you were running 10 applications out of process, you would find 10 separate Mtx.exe files.) If your application fails, the associated Mtx.exe fails, leaving either the Inetinfo process or your Web server intact. Once you’re confident that the application is reliable, bring it into the Inetinfo process by clearing the Run in own memory space check box, which can be found in the application’s property sheets.

Running applications out of process is an important feature for ISPs because many of their customers want to use custom components. If these components are run in process, it is common to see that the Inetinfo process is exceeding normal performance parameters and, as a result, to falsely assume that IIS 5.0 is running poorly. But in reality the poor performance is usually caused by a custom component that is leaking memory. Had that component been run in its own memory space first, the associated Mtx.exe would have reflected the performance cost. The solution, accordingly, would have been to end the Mtx.exe process, not the Inetinfo process.

It can strain your computer’s resources to run applications out of process, since doing so takes away resources from the Web server. Despite this drawback, it is best to initially run new applications out of process to make sure they are stable and meet your requirements. Once you have done that, you can then safely run them in process.

Here are some guidelines on running various types of applications in and out of process.

Common Gateway Interface (CGI) applications are run out of process, but they offer poor scalability. In other words, every instance of a CGI application requires the creation of a new process with its associated overhead, and application parameters are passed through environment variables.
ISAPI applications can also be run out of process. When you do this, you’ll attain the same level of application integrity as CGI applications, but with faster performance. You can further improve performance by running ISAPI applications in the same memory space as the server (in-process). Remember that in-process applications don’t yield as much application integrity as those run out of process.
Some ISAPI dynamic-link libraries (DLLs) can’t be isolated. Examples include DLLS that rely on locking resources, such as open files, shared memory, and so on. In such cases, you should rewrite the application to remove the dependencies.
An individual server can host a mix of in-process and out-of-process applications. With this mix, you can run well-tested applications in-process for faster performance, and run others out of process during development or beta stages for “fail-safety” reasons.
Note While both ISAPI and ASP process isolation are managed through Microsoft® Component Services, process isolation is managed through the IIS snap-in.