|
Running ISAPI applications Within IIS 4.0
The next version of the Internet Information Server, version 4.0, is a major change from version 3.0. One of the biggest improvements is the ability to run ISAPI applications in another process space. Version 3.0 of IIS and the previous versions required that all ISAPI applications run within the process space of the server. An ISAPI application is an extension to the server that allows programmers to write dynamic web pages. Both Active Server pages and the Internet Database Connector are ISAPI applications. The three main improvements in application management are:
- The ability to run ISAPI applications outside of the process space of IIS.
- The ability to load and unload ISAPI applications without effecting the rest of IIS.
- The ability for IIS to start a new instant of an ISAPI application, after it's failure.
ISAPI Performance
One of the biggest advantages of an ISAPI application in IIS 3.0 is that it is fast. It is fast because once the server loads the ISAPI application into memory it is not released, making other calls quick because the operating system need not load the DLL again. Comparably, CGI executables are instantiated every time that they are called. The loading and running of the executable slows the response time of the page.
ISAPI State
Another advantage of loading ISAPI applications in IIS 3.0 into memory and not releasing them is that you can maintain state across multiple calls. By having global variables, protected with critical sections, you can save information about the application that spans several requests. This is usefully when you implement ODBC connection caching for additional speed. In comparison, CGI executables do not have a way of maintaining state across multiple requests.
ISAPI Stability
One thing that CGI executables do have in their favor is that they are more stable then ISAPI applications. In fact, they are not more stable, but they give the appearance of being more stable. This is true because of one single fact, if your CGI executable has a general protection fault, or crashes for some other reason, only one user is effected. This is because the general protection only effects the process that it is running in. General protection faults in ISAPI applications effect the process they are running in also, except they are running in the application process that the web server is running. ISAPI applications that crash usually crash the server also. The difference here is that ISAPI application crashes effect all the users that are currently on web site and usually all the users that follow the crash, while CGI executable crashes only effect that user.
ISAPI Programmability
Because ISAPI applications must be crash proof in IIS 3.0 there are few people qualified to write ISAPI applications. It takes are very good disciplined programmer to write crash-proof applications that handle all the error checking without effecting the other threads that are also running within the application. Besides the responsibility of writing rock hard applications, developers also have to deal with a wide range of varying input, since the user scenario of the Internet is very broad. Developers that came from writing Windows executables, where they could pass the error messages onto the user, are suddenly faced with a scenario where they must handle the error messages themselves within the code. Another thing that new ISAPI programmers face is the lack of leniency of memory leaks. Windows programmers in the past have been able to disregard small memory leaks in lieu of bigger bugs. However ISAPI applications, because they never unload, begin to consume large amounts of memory from even the smallest memory leaks. These things in combination have made ISAPI programming tough.
IIS 4.0 Flexibility
IIS 4.0 gives you more flexibility to manipulate ISAPI applications. You can choose to have the ISAPI applications execute within the server process, or in a separate process. You can also have the ISAPI applications remain loaded or unload after every request.
IIS 4.0 Application Namespace
IIS 4.0 allows you to run your ISAPI applications in a separate process space. The advantage here is that if the ISAPI application crashes, then neither IIS nor other applications are halted. In IIS 4.0 you cannot isolate the ISAPI individually, instead all ISAPI applications are isolated within the namespace of an IIS application. In order to run all ISAPI applications in a separate namespace you must create an application namespace. Here is how:
- Open up the Internet Server Manager within MMC.
- Click on the directory that you want to begin your application namespace at.
- While your directotry is selected, right click and choose Properties from the drop down menu.
- Depending on the type of directory, click on either the Home Directory, Virtual Directory, or the Directory tab.
- From within the Application Setting click on Create. This will create an application namespace that incorporates all the subdirectories physically under that application.
- Click on OK to exit.
Figure 01 : Create Application Namespace
IIS 4.0 Application Isolation
Once you have an application namespace created, you can separate all the ISAPI applications and have them run from within a separate application. Here is how:
- Open up the Internet Server Manager within MMC.
- Click on the directory that you want to begin your application namespace at.
- While your directotry is selected, right click and choose Properties from the drop down menu.
- Depending on the type of directory click on either the Home Directory, Virtual Directory, or the Directory tab.
- From within the Application Setting check the box that says Run in separate memory space.
- Click on OK to exit.
IIS 4.0 Isolation Scope
By isolating all ISAPI applications to an application namespace, you not only isolate your ISAPI application but all Active Server pages and Internet Database Connector calls as well. For instance, lets say that you have an ISAPI application called myisapi.dll. The normal way that you call that application is by typing this into your browser:
http://www.myserver.com/scripts/myisapi.dll?Name=Value
Since myisapi.dll might crash the server, you play it on the safe side and isolate the DLL by creating a separate memory space for the myisapi.dll to run in. This application namespace includes /scripts and all of scripts subdirectories. However, also within scripts is some Active Server Pages. To request these, you can type this URL in the address space of your browser:
http://www.myserver.com/scripts/mypage.asp
Since you have isolated all applications running under the scripts virtual root, the request to the Active Server page will also run in a separate process from the server. This is because the .asp extension is mapped to the ISAPI application asp.dll. Active Server pages are implemented through an ISAPI application. Since the .idc extension is mapped to httpodbc.dll and the Internet Database Connector is an ISAPI application it to will run in an isolated process.
What is the WAM
Now that you have the basics of application isolation, lets see how it is handled. The Web application manager (WAM) implements process isolation. For each application namespace that is configured, there is a separate instance of the WAM. Think of the WAM as an executable that can load your ISAPI DLLs and direct requests from the IIS server to those calls. Since the WAM is an executable, it has it's own process space that is outside of the Internet Information Server. Each application namespace and the DLLs that are running within that application namespace are running in their own process space. The WAM, once started, does not close and restart for each request. It remains open to handle other requests. Once an instance of the WAM loads an ISAPI DLL, the DLL remains loaded so that it can handle other requests.
How the WAM works
When IIS 4.0 receives a request, it figures out what application namespace that the request is going to. If the request is going to an application namespace that is isolated and an instance of the WAM doesn't exist for this application namespace, then a WAM is created for that namespace. Once the WAM is created, it loads up the ISAPI DLL that supports that request. Once the request is handled, the WAM remains open and the ISAPI application remains loaded. When another request comes in for that same namespace, then the WAM is used. If for some reason the ISAPI DLL crashes and the WAM is closed. The next request for that namespace will open up a new instance of the WAM. This is the second big advantage of process isolation, not only does a bad ISAPI DLL not crash IIS, the next request is not inhibited by a previously failed request.
Unloading the WAM
IIS 4.0 also allows you to unload the instance of the WAM for a particular namespace. This is how:
- Open up the Internet Server Manager within MMC.
- Click on the directory that you want to begin your application namespace at.
- Right click on Properties .
- Depending on the type of directory click on either the Home Directory, Virtual Directory, or the Directory tab.
- From within the Application Setting click on the Unload button.
- Click on OK to exit.
Unloading the WAM unloads both the instant of the WAM executable and all the ISAPI DLLs that that particular instant of the WAM has loaded. This is usefully when you want to replace components with out stopping the rest of the web server. Just unload the application space and replace the component.
ISAPI Considerations
Because of the WAM, some ISAPI DLLs that run well under IIS 3.0 will not run well when isolated under IIS 4.0. Specifically, ISAPI applications that cannot have two instances of the same DLL running at the same time. If you have two application namespaces that are both set to run isolated, and within the two namespaces you have the same ISAPI application, then you can possible have two instances of the ISAPI running. Once instance would be loaded by one instance of the WAM executable, and the other instance would be loaded by the other WAM executable. The NT operating system has no problem loading two different instances of the same DLL. However you need to take into consideration that there might be two open instances. Make sure not to lock resources like files or shared memory from within the ISAPI application.
ODBC Connection Pooling Considerations
Because ODBC Connection Pooling is turned on or off on the process level, running ISAPI applications in a separate process space means that you will have to turn connection pooling on within every ISAPI application. In IIS 3.0, where all ISAPI applications are run within the same process, having connection pooling turned on for Active Server pages meant that connection pooling was turned on for all other ISAPI applications as well. However, if you run your ISAPI applications in a isolated process space then you will need to turn connection pooling on from within each application. This also means that you can turn connection pooling on or off from within each application namespace. So you could have half of your Active Server page configured to be using connection pooling and the other half of your Active Server pages configured to not use connection pooling as long as your application namespaces are isolated.
Active Server Page Considerations
Besides the ODBC connection pooling, other attributes of Active Server pages can be configured per process, including the script timeout period, session handling and script caching. Unlike IIS 3.0, the WAM allows you to configure these options per application space, instead of per machine.
Performance Considerations
Applications running within the same process space as the Internet Information server will run faster then isolated processes. The WAM has additional overhead of communication between the Internet Information Server and itself when isolated. Plus, the WAM has a one-time startup cost of loading the WAM executable and loading the associated ISAPI applications. Besides the performance cost, there is a memory cost associated with running each WAM and the additional DLLs. However, isolated applications run faster, after the first request, then CGI executables.
ISAPI Application Caching
Like previous versions of IIS, IIS 4.0 allows you to cache ISAPI applications. This means that once loaded either by IIS or the WAM ISAPI, DLLs are not unloaded until either the server is stopped of the application namespace is unloaded. Because of the startup cost associated with loading a DLL, caching makes the response time faster then a CGI application that must load and unload executables.
In IIS 3.0, you could configure all the ISAPI DLLs to either cache or not cache. In IIS 4.0 you can configure each namespace separately. This granularity allows you a greater degree of control. By default, each application namespace caches the ISAPI applications that reside within it. Here is how you turn caching off:
- Open up the Internet Server Manager within MMC.
- Click on the directory that you want to begin your application namespace at.
- While your directotry is selected, right click and choose Properties from the drop down menu.
- Depending on the type of directory click on either the Home Directory, Virtual Directory, or the Directory tab.
- From within the Application Setting click on the Configuration button.
- From with in the Application Configuration dialog click on the Application Mappings tab.
- Uncheck the box with the label Cache ISAPI Applications.
- Click on OK to exit the Application Configuration dialog.
- Click on OK to exit the properties dialog.
Figure 02 : Turning Off Caching
|
