Improving the Performance of ISAPI Applications – Profiling the ISAPI DLLs

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 performance related issues.

ISAPI Applications are meant to run on 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 IIS process address space thus interacting with IIS and other ISAPI DLLs also. One thing has to be kept into mind that since 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 initializes. All these worker-threads accept the incoming HTTP requests and process them. If the ISAPI filters are configured to run, then it loads the ISAPI Dll. 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 as name and version, etc.). Then, the HttpExtensionProc is called. The DLL remains in 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, since ISAPI runs in the IIS process address space, the chance of corrupting the memory space of IIS are high (although the thing worth noting 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 over-head). Most importantly, the multithreading issues have to be taken into consideration. Since ISAPI DLLs are called upon by number of threads at a time thus 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 absolutely needed, otherwise use critical sections.

To determine the bottlenecks in your ISAPI application, we need to do profiling of the ISAPI DLL. Well, 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 and thus detecting the bottlenecks of the application. 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 figure below:

   

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 _LL extension. This self-profiling file would keep the record for function-timing, function-counting, function-coverage. This would generate a file named yourISAPI._LL.
3. Rename the original DLL to something else and name this DLL (with _LL extension as .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, Profile.ini.
6. Set the __ProfileBPI and __ProfileBPO system environment variables to the path of your PBI and PBO file that will be generated when you run the prep command.
7. Stop and restart IIS so the profiled DLL is loaded.
8. Run the application, i.e., 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 PBI and PBO files are located.

Prep /m yourISAPI Plist yourISAPI

Note: DO NOT PUT IN EXTENSION-ONLY NAME OF THE DLL HAS TO BE GIVEN.

Prep /m will merge the statistics gathered and generate .PBT file, and plist will format the .PBT file into 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 command line. 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 take rectifications for the bottlenecks.

Hope this will help all of you.

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.