Since I use ASP.NET HTTP handlers quite often, I decided to figure out what advantages IHttpAsyncHandler has compared with IHttpHandler. As I looked at many people's claim that IHttpAsyncHandler somehow magically improves performance by shifting request processing on to another thread, I realized that MSDN documentation of IHttpAsyncHandler is laking in a fundamental way: it fails to mention that simply moving request rendering onto another thread does not yield any benefit.
When you simply move your request handling logic from the original ASP.NET thread to your own thread (IHttpAsyncHandler), you gain exactly nothing because both threads come from the same pool. The benefit of IHttpAsyncHandler comes in only when your request processing thread is blocking, waiting for another thread. For example, if your request processing calls a web service, your request processing thread will wait for the IO completion happening on another thread - where request is sent to the web service. In this case there will be two threads involved: your request processing thread, and the IO thread where outgoing web service request is being executed. This is the situation where IHttpAsyncHandler can help: instead of holding on to the request processing thread while waiting for the outgoing request to complete, one can release the original request processing thread back to the pool, and finish response rendering on the IO thread after the web service request has completed. This way, instead of holding two threads for the duration of the relatively long-running process of invoking a web service, your request processing is using only one thread.
So, the bottom line is this:
- You should only concert yourself with IHttpAsyncHandler if you are running out of request processing threads.
- If you do, check your logic for whether it's waiting for an IO completion (or is using other threads for other reasons), and only if that's the case, switch to IHttpAsyncHandler.
- Otherwise simply increase the size of the ASP.NET thread pool in the web.config and stick with good ole' IHttpHandler.