locked
Simultaneous requests to ISAPI filter RRS feed

  • Question

  • User-1252038469 posted

    Hello,

    I have written a ISAPI Filter to process all browser requests that hit my IIS 6.0 Server. It appears that IIS 6.0 only allows 2 requests to be processed by the Filter at any time, with the others being queued. The queued requests are sent to the ISAPI Filter after earlier requests are processed.

    Changing the number of 'simutaneous connections' to 'Unlimited' in the Performance Tab of the IIS control window does not seem to help.

    Can someone please tell me how I can increase the number of simultaneous requests that can be processed by the ISAPI Filter?

    Thanks & Regards,

    Anand

     

     

    Thursday, June 21, 2007 4:15 AM

All replies

  • User511787461 posted

    IIS on server skus does not have any such limits - it will call your ISAPI filter with unlimited number of concurrent requests - the exact number would depend on your cpu load, number of incoming requests etc - you either do not have enough incoming requests, or your cpu is already pegged.

    Thursday, June 21, 2007 8:28 AM
  • User-1252038469 posted

    Hello Anil,

    Thank you for your reply.

    We use Windows 2003 Server (SP2). We tried our experiments on a single Processor (2.4GHz) machine, and then on a Dual Processor Machine (2 x 3GHz). In both cases, we observed the HTTP requests being queued by the IIS 6.0, with only 2 requests being passed on to the ISAPI filter. Also, the CPU Load (as seen from the Performance tab of the Task Manager) hardly shows any load when the HTTP requests are queued.

    Am I missing something obvious? Maybe a setting or something? Maybe a registry key?

    I read that IIS has max limit on simultaneous threads but does it also pipeline?

    Regards,

    Anand

     

    Thursday, June 21, 2007 9:18 AM
  • User511787461 posted

    What are you using to generate load on the machine?  What is the number of concurrent connections/requests to the server?

    Thursday, June 21, 2007 1:35 PM
  • User-1252038469 posted

    Hi,

    We are using bots (which basically are web-clients) we have written to test this over the LAN. Each bot can randomly generate hundreds of requests in short time. A total of 6 computers run the bots on the LAN on which the IIS 6.0 Server is also installed.

    We also generate timing logs of when each ISAPI request is triggered, and when each request processing ends. We notice that a new request is triggered on the same millisecond when a prior request processing ends, in such a manner that at any time, only 2 requests are forwarded to the ISAPI for simultaneous processing. This is observed many hundreds of times. Surely, such a timing synchronization is too much of a coincidence?

    Morever, by studying the network traffic using Ethereal (traffic analyzer utility), we notice that there is a delay of several seconds between the time a requests hit the IIS computer and the time the ISAPI is invoked for that request.

    Everything seems to indicate that IIS 6.0 is doing some sort of queuing, with only 2 requests being processed in parallel by the ISAPI.

    Thank you again for taking the time to respond.

    Tuesday, June 26, 2007 5:05 AM
  • User511787461 posted

    I don't know what to tell you, if you put a Sleep(INFINITE) in your ISAPI filter and let the server run for a bit and break into the debugger, you will see upto 256 threads in your ISAPI filter, if you are not seeing enough threads in the ISAPI filter with the current code and load, it is a function of the load and whether the code is cpu or I/O bound - the only IIS limit of concurrency is around 256 threads.

    Monday, July 9, 2007 9:36 PM
  • User209782248 posted

    Anand,

    Also, what content are you making the request to (ASP, ASPX)?  If there is anything else in your system serializing the request processing, that may happen.

    Are you seeing any queueing in the application pool queue via the Http Service perf counters?

    What is your CPU usage?

    Thanks,

    Mike

    Friday, July 27, 2007 3:21 PM