HttpModule threading

Question

Trawling through the 'net I'm getting lots of conflicting posts as to whether the HTTPModule route is single threaded or multithreaded by default.

I'm trying to debug rapidly differing performance within local, UAT and deployment environments and am wondering whether there is a pinch point with HTTPModule that I've been previously unaware (given CPU and memory in all environments is next to nothing).

One previous disturbing post suggested that all requests are pooled then fed to the module sequentially (each waiting for the previous request to finish before starting the next).

Answer 1

As far a I know, threading for HttpModule instances is the same as for HttpHandler instances. When a request comes in, a worker thread is allocated from the thread pool and is used to execute the request. So modules run asynchronously.

I found this article very useful in understanding threading in the asp.net pipeline.

One factor that could affect perf is the size of the thread pool. By default the pool contains (I think) 25 worker threads, but this can be changed in machine.config. Could this be the case in the environments you are investigating?

Also, threading is subtly different in IIS5 and IIS6 (see the article lined above). Could this be explain the differences you are seeing?

Answer 2

Thank you for this, I believe I may have found my bottleneck and put in a temporary work around by:

Changing the machine.config to:

  <section name="processModel" ... allowDefinition="MachineToApplication"/>

Restarting IIS and updating the web.config System.Web with:

<processModel enable="true" ... maxWorkerThreads="100" maxIoThreads="100" />