Improving the Performance of ISAPI Applications -- Profiling the ISAPI DLLs

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).



    Click here for a larger image.

  2. Run this command at the command line on your ISAPI DLL:
  3. 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.

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

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

  6. 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>

  7. 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.

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

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

  10. 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.



Comments

  • Improving the Performance of ISAPI Applications--Profiling the ISAPI DLLs

    Posted by Legacy on 06/20/2003 12:00am

    Originally posted by: Wayne Berry

    This is only for Visual Studio 6.0, what about Visual Studio .NET with C++ ISAPI Extensions?

    • There is a ISAPI debug tool available for .NET

      Posted by tarundsk on 03/24/2004 01:48am

      there is isapi debug toold available with .NET
      You can also profile it this way

      Reply
    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: May 6, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT While you likely have very good reasons for remaining on WinXP after end of support -- an estimated 20-30% of worldwide devices still are -- the bottom line is your security risk is now significant. In the absence of security patches, attackers will certainly turn their attention to this new opportunity. Join Lumension Vice President Paul Zimski in this one-hour webcast to discuss risk and, more importantly, 5 pragmatic risk mitigation techniques …

  • Live Event Date: May 7, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT This eSeminar will explore three popular games engines and how they empower developers to create exciting, graphically rich, and high-performance games for Android® on Intel® Architecture. Join us for a deep dive as experts describe the features, tools, and common challenges using Marmalade, App Game Kit, and Havok game engines, as well as a discussion of the pros and cons of each engine and how they fit into your development …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds