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 process handling 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 benefits. The doc fails even to mention the goal of IHttpAsyncHandler is pretty much just to manage ASP.NET request thread pool more efficiently. This means that your application using synchronous IHttpHandler will suffer performance penalty only when your application runs out of threads dedicated by ASP.NET to handling requests. This means that, first, it makes sense to consider switching to IHttpAsyncHandler only if your requests are high-latency. However, even then switching to IHttpAsyncHandler may not provide any performance gain unless bulk of requests processing (or waiting for conditions allowing processing to begin) occur on a thread other than one coming from ASP.NET thread pool!!
Creating your own thread does not make anything any more efficient, because releasing request processing thread to create your own has a zero net result. In this situation you can achieve better net result by increasing the size of ASP.NET thread pool by tweaking web.config.
The benefit of using IHttpAsyncHandler, as I understand it, comes only when your request-processing thread is waiting for an I/O completion, like a web service call, for example. In this case, another thread, the IO thread, is created, and instead of waiting for the I/O port completion on the request-processing thread, it makes sense to release the processing thread and tell I/O thread to call you back when IO is completed, effectively finishing response processing on the I/O thread. In most cases this means that unless your BeginProcessRequest() implementation starts an async I/O operation that takes async callback as a parameter, the whole IHttpAsyncHandler business is a waste of time.
The rule of thumb should be this: if most of your request processing is done by a callback invoked in response to an I/O completion, and therefore on the IO thread, then usage of IHttpAsyncHandler is justified. Otherwise, I am sticking to good ole' IHttpHandler.