ISAPI Filter and the N+1 Architecture?


Hi David,

I am developing an ISAPI Filter to prove the N+1 Architecture.There will be few static sites, few dynamic sites and few cgi perl script sites will be there. Can you please tell me how ISAPI performs for CGI Perl Scripts.

Thanks and Regards.


How ISAPI performs on IIS completely depends on how its author writes it. ISAPI is a thin wrapper that allows you to run raw Win32 code on IIS, so it is as fast as you can get. Thus, the real question is whether you can write the ISAPI Filter performantly for your N+1 experiment?

I really do not know what you plan on writing, so I cannot offer any additional advice other than if you do things incorrectly, ISAPI Filter can also strangle/crash IIS very easily. With power comes responsibility. Choose wisely.

Now, I can say that launching CGI Processes to execute scripts will likely be one of the slowest part of the website, so you want to optimize and use ISAPI versions of everything. So, you want to use an ISAPI version of Perl to execute Perl Scripts.

You may want to browse through other blog entries for general thoughts. Some of them include:


Comments (8)

  1. anonymous says:

    sorry if this is too basic – but what do you mean by ‘N+1’ architecture?

  2. MK says:

    Few quick and friends thoughts looking for input, suggestions or fixes..

    Seems to me, unless I’m missing something, probably one of the most irritating aspects of IIS development is the fact the debugger cannot be easily attached once an ISAPI error is triggered. One example being assertions triggering the line of code in question and inetinfo subsequently crashing on attempt to attach the debugger from the dialog.. Another one being crashes and lack of offending stack information in case of say atl server.

    It just becomes very hard to identify what and where the offending code is at least for apps configured to run with the inetinfo.. Coupled with VS.NET having serious issues with native and/or script debugging (spec. script variables in Watch window, breakpoints not going away, and workspace documents order and visibility not getting stored right) all make this process close to a nightmare.

    Hope to provide some specific data as it comes in view on load tests.. in any case, nice to see IIS and HTTP blogs out there.. keep it up.

  3. David Wang says:

    MK – actually, I haven’t encountered any of the problems you stated regarding Script nor native-code debugging. That is pretty much bread-and-butter of the IIS product and tests, and I think it works pretty well on all of the recent Windows OS releases the last time I checked.

    In general, the right way to debug is to attach the debugger BEFORE the error is triggered. Then, you can either step through the offending code or catch the first-chance exception and handle it in the debugger up front.

    I have no idea how you are trying to debug assertions in native code nor problems with stack information – I have never seen any problems with it and we use pretty much the same tools / configurations that you do. It sounds like you are trying to rely on catching second-chance JIT exception, which may not be what you actually need to do.

    I have seen some minor script debugging issues with later versions of VS.Net (mostly because seamless debugging Scripting is considered legacy and not really maintained on the later versions), but the original Microsoft Script Debugger still works pretty well up through WS03SP1. I really do not debug scripts using VS.Net.

    So all in all, I am curious about the specifics of your debugging issues because my experience has been pretty much the opposite.


  4. MK says:

    Thanks for your reply David.

    It was not a decent criticism by any means from me, and I can understand some bits being very hard to reproduce and that they are very rare. Overall the tools are great, my experience with complex debugging issues under it somewhat limited etc.. So that out of the way..

    Unfortunately, I cannot attach the debugger before. Many times before hitting the production setup/environment debug builds are run for days to identify and ideally log anything that might be suspect.

    As you are aware, the debugger attachment brings in considerably heavier CPU utilisation from the env and naturally might cause less races or violations than unattached or, less releveant here, release code..

    To clarify further, here’s a specific scenario.. the service provision code that will run within IIS is build as a console or other type of project first, a ‘module’ in its own right but reused on compilation for ISAPI component.. natural choice to make the project more maintainable, reusable for other types of apps etc..

    Therefore, it contains asserts, ATL type or other.. It also might not use C++ exceptions at all, even STL build, for other reasons you’ll appreciate as well as that IIS is not the only target..

    Under IIS, some of those asserts will actually be interactive asking for a debugger to be attached etc.. some will be ‘silent’ I believe, pretty confident on this.

    Now in case of a bug I could not anticipate/precondition in code, ie. no assertion or similar, the only chance to see it would be the C++ exception handler in ATL server. From there we can see the handler in question and try to dig back through the code.. but it often isn’t enough. So I guess I have no option but to run under debugger..

    And if the above case is somehow missed the next step is INETINFO going down which leaves me guessing until the next repro, the worst-case of all ;-)..

    To be completely frank, I’m getting better at chasing them but might require a different approach and more reading on debugger setup for non SEH exceptions or somehow resort to attachment before IIS manages to crash due to my bugs of course..

    This is all complicated further because my debug setup uses components that must maintain ping-type communication and therefore limit my time in the debugger or heavy user/CPU test-cases..

    All excuses of course, and I am somehow having more trouble than usual but will give it more thought.. To make it absolutely clear, IIS is never at fault, and issues caused only by my code, naturally 😉 Thanks for your input..

    Regarding script+native debugging.. it took me quite a few weeks to figure that assignment in Watch window for a script variable managed to interfere with native C++ code variable with same name.. all of which caused totally random behaviour, have 79 gray hairs to prove it 😉

    Of course once again my fault but it could save others some time 😉 Another instance is hangs in expansion of objects in Watch window, sometimes VS crashes.. then there’s breakpoints, document workspace setups not rememberd ..

    But have taken your comments onboard and will resort to MSD for scripts.. it’s just awesome to be able to walk environments and see the flow in action. If the above was supported and E&C worked under IIS, heck life would be a peach 😉



  5. David Wang says:

    MK – I see. Your problems are similar to the sort that we had to solve for IIS6, so let me recap some of our strategies that may be helpful for you.

    Our primary rule is that assertions and debug spew (via OutputDebugString) are used liberally, but only apply for debug builds. Release builds never assert and never spew into the debugger.

    This means that it is always safe to attach a debugger onto a process because the only time an "exception" happens is an unexpected one (and with a debug build, usually the assertion fires first, before the exception from the crash). Debug symbols are always used to resolve the line numbers of offending source code.

    And since we attach debuggers onto the processes of interest from the very beginning, we never lose a crash investigation of an unhandled exception.

    In the cases where timing is important, we enable the kernel debugger port in boot.ini and use the -d option of NTSD/CDB to pipe everything to KD, and then leave the KD unattached. This means that the machine freezes only when the exception happens, and then we activate and attach the KD to investigate the user-mode exception… only good for debug setups, of course.

    In other words, we never rely on second-chance or JIT debugger popping up that UI. We also do not use VS to debug – we use the debuggers from the freely available Micrsoft Debugging Toolkit – NTSD / WINDBG / KD. They give a comparable debugging experience that is reliable and ultra-lightweight.

    With IIS6, you realize that debugging w3wp.exe also has a similar ping-communication-maintenance problem. What we did to solve this problem was make the remote "ping validator" realize that the w3wp.exe has an active debugger port (or process PID does not match w3wp.exe reported PID) and in those cases, "orphan" and ignore that w3wp.exe. All configurable, of course. This means that when you configure ImageFileExecutionOptions to attach a debugger onto w3wp.exe, IIS6 will automatically ignore it when under debugging.

    Finally, we constantly run our debug builds until it runs 100% clean, without crashes or bogus assertions firing, for at least 21 consecutive days under stress… until near release time.

    Of course, this is all secondary to any trace logging you may employ in your application to help flag suspect situations.

    Hope some of this helps.


  6. MK says:

    Awesome input, thanks, may it show the way of the web 😉

    Have certainly some homework to catch up with, look up those kits and take everything suggested into consideration. If it proves necessary certainly have no issues switching debuggers as soon as time permits.. What’s the worse than can happen, KD will feel like good old 80’s, text and text only.. UIs are so outdated anyway (g).

    Unfortunately the ping communicator is not under my control, can be switched off but brings in heavy duty issues with it’s own session/lifetime or indirectly impacts loads of ‘ownership’ and load balancing logic for tests at the very least (it’s worse than that really, the DLL is not doing any ‘versioning’ and contains a messed up dm-switch impl).. for all I care it’s vendor/provider loss, am talking to them and might be lucky and see it fixed.

    In any case, many thanks for your help once again.. look forward to adopting some methods suggested or similar.

    While here, please keep up the great work and all the best for release of the IIS7.0 monster-server 😉 Just to let you know, this is really why I stopped writing TCP servers.. why on earth bother, you guys do so much on testing, tuning, and features that it’s just pointless. If there only was something better than chunked-encoding for HTTP I really wouldn’t use anything but IIS..

    So can we ‘hook it’ lol and tweak that please? Joking of course..IIS and SSL blogs, all that’s needed 😉 If only IE bloggers could respond to some recent, very much needed, requests regarding performance of their rendering and scripting engine before new release, fingers crossed..



  7. David Wang says:

    MK – Thanks for the encouragement.

    With IIS7 you’ll finally be able to reconfigure it to be your precisely customized TCP server, running exactly the modules you want and nothing more…

    Not that the extra IIS modules are the cause of your current problems… 😉 But we are very keen to get our modules off the radar so that it eases our servicing requirements while simultaneously improving your reliability requirements. win-win for everyone.


  8. MK says:

    In fact I’m secretly hoping it would go beyond some HTTP limitations (or for purists, offer ‘plugability’ for other things than Web;).. why not.

    Perhaps should be identical and related to some (hopefuly fresh) MSMQ bases.. some reuse, who knows, something as long as we can reuse and be safe in knowledge it can’t be really done better with x number of years of work 😉

    Writing TCP servers/protocols will be to a good extent specific anyway.. so yes, it’d be darn cool to see this happening.

    I am really becoming more comfortable than ever using MS stuff for high-load apps .. and tests show some paths are working pretty amazing on stress.

    Hate to repeat but might be worth something.. wish I could say the same for client/IE, which is a great shame. Someone really needs to alert them to speed that painting and JS interaction up by all means necessary ;).. anything but whack the CPU to max..

    Very OT, my apologies, probably the blog ‘popularity’ causing no response ;), but somehow feel the entire package/path is important.. so while server part seems well taken care of, it still feels useless to go Web without a good/responsive/scalable client.

    IIS is behaving so well I am very happy, somehow knew I shouldn’t worry about it’s load or CPU hit even from 5.1.. and data confirm it too..

    All the best..