Improving the Performance of ISAPI Applications — Profiling the ISAPI DLLs

CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Environment: VC++ 6.0, Win2k

Introduction

ISPAI applications are meant to be run on Web Servers and ISAPI developers like me often face ISAPI-related performance issues. Here is a brief discussion on how to profile an ISAPI DLL and determine and solve the performance-related issues.

ISAPI applications are meant to run in a High-load environment and the IIS Server has to respond to several hundred (ideally more than that) requests per second. To improve the performance of the ISAPI applications, first of all it is very important to understand how ISAPI works on IIS.

Understanding ISAPI Execution

There are two types of ISAPI programs for the Web Servers—extensions and filters. These are DLLs that run in an IIS process address space, thus interacting with IIS and other ISAPI Dlls, also. One thing that has to be kept into mind is that, because Web Servers (yes, ISAPI is not only for IIS, but for lots of many servers—almost all server vendors provide the APIs to extend the functionality of the Web Servers) can handle more that one request at a time the ISAPI DLL can be called upon by more than one thread concurrently. During the server startup (web-publishing service-w3svc), all the initialization takes place; it checks and loads the ISAPI filters from the Registry. Then, the worker pool threads of IIS initialize. All these worker threads accept the incoming HTTP requests and process them. If the ISAPI filters are configured to run, it loads the ISAPI DLL.

The ISAPI DLL is like any other regular DLL. The ISAPI Dll is then registered by calling GetExtensionVersion (which is called only once and contains registration data, such as name and version and so forth). Then the HttpExtensionProc is called. The DLL remains in the process address space until the execution is going on. During IIS Shutdown procedures, all the loaded DLLs are unloaded and all worker threads are stopped and IIS stopped.

Now, because ISAPI runs in the IIS process address space, the chance of corrupting the memory space of IIS is high (although the thing worth noticing is that IIS allows you to debug and test ISAPI DLLs in isolation mode but that will reduce the server performance and will be an overhead).

Most importantly, the multithreading issues have to be taken into consideration. Because ISAPI DLLs are called upon by a number of threads at a time, our code needs to be “thread-safe” (also keep in mind not to lock resources in threads). Avoid global data structures in your DLLs unless they’re absolutely needed; otherwise, use critical sections.

Now, to determine the bottlenecks in your ISAPI application, we need to do profiling the ISAPI DLL. By profiling, we mean examining the run-time behavior of the application to determine the performance of the various sections of the application and knowing which sections are taking how much time, thus detecting the application’s bottlenecks. Profiling an ISAPI DLL is a very important part of determining and improving the performance of the DLL.

Profiling the ISAPI DLL

The steps to profile your DLL are:

1. Build the DLL, enabling the profiling and generation of map files in linker options (see the following figure).

   

2. Run this command at the command line on your ISAPI DLL:

Prep /om /ft yourISAPI.dll

This command will create a self-profiling DLL with an _LL extension. This self-profiling file would keep the record for function timing, function counting, and function coverage. This would generate a file named yourISAPI._LL.

3. Rename the original DLL to something else and name this DLL (with an _LL extension as a .DLL).

4. Copy this profiled DLL and profile.dll to the Web Server where you want the ISAPI to run.

5. Copy the following file from yourDriveLetter:\ProgramFiles\Microsoft Visual Studion\VC98\Bin directory to the same place where you copied the DLLs.

   The files to be copied and put are Profile.EXE, Profile.DLL, and Profile.INI.<.p>

6. Set the __ProfileBPI and __ProfileBPO system environment variables to the path of your PBI and PBO files that will be generated when you run the prep command.

7. Stop and restart IIS so that the profiled DLL is loaded.

8. Run the application; in other words, send the request to your ISAPI so that ISAPI is executed, and then stop the IIS after execution.

9. Run the following commands in the directory where the PBI and PBO files are located.

   Prep /m  yourISAPI
   Plist yourISAPI
   

Note: Do not put in the extension; only the name of the DLL has to be given.

Prep /m will merge the statistics gathered and generate .PBT file; plist will format the .PBT file into a text file. Now, you can have the input of the PBT file to the text file you want.

For example, plist yourISAPi > Profile1.txt on the command line.

Now, you can easily see which section of your code is taking how much time. And, now that you have an analysis of the section based upon time (which is critical for Web applications), you can remove and make rectifications for the bottlenecks.

I hope this will help you all. In case you need any help, please do e-mail me.