Performance difference between Synchronous HTTP Handler and Asynchronous HTTP Handler

Question

Is there a performance difference between Synchronous HTTP Handler and Asynchronous HTTP Handler? IHttpHandler vs IHttpAsyncHandler

Why choose one over another?

What are the benefits?

Oakleil

Answer 1

ASP.NET uses the thread pool to process incoming HTTP requests.

When an IHttpHandler is called, a thread pool thread is used to run that request and the same thread is used to process the entire request. If that request calls out to a database or another web service or anything else that can take time, the thread pool thread waits. This means thread pool threads spend time waiting on things when they could be used to process other requests.

In contrast, when an IHttpAsyncHandler, a mechanism exists to allow the request to register a callback and return the thread pool thread to the pool before the request is fully processed. The thread pool thread starts doing some processing for the request. Probably calls some async method on a database call or web service or something and then registers a callback for ASP.NET to call when that call returns. At that point, the thread pool thread that was processing the HTTP request is returned to the pool to process another HTTP request. When the database call or whatever does come back, ASP.NET triggers the registered callback on a new thread pool thread. The end result is you don't have thread pool threads waiting on I/O bound operations and you can use your thread pool more efficiently.

For very high concurrency applications (hundreds or thousands of truly simultaneous users), IHttpAsyncHandler can provide a huge boost in concurrency. With a smaller number of users, there can still be a benefit if you have very long running requests (like a Long Polling request). However, programming under the IHttpAsyncHandler is more complicated, so shouldn't be used when it isn't really needed.

Listlessness

Thanks for answer @Samuel Neff, can you please share links where I can read about difference of usage a bit more. Need to get it absolutely clear. – Kistner

Answer 2

There's no performance difference aside from managing another thread.

Synchronous is easier to code. You send the request and the thread freezes until the response is returned. Then you can handle the response and errors in the same method. It's easy to read and debug. If you run this code in your GUI thread, Windows may report that your program is "not responding" if you don't receive a response quickly.

Use Asynchronous if you don't want your thread to freeze. The user can continue to interact with the program while a background task waits for the HTTP response. Then you have to write code to manage the background task, watch when it is complete, handle errors, pass these errors back to the GUI thread, etc. It's a bit more work, and a lot harder to read and debug, but ultimately a better quality product if it's done properly.

Edit: Corrected that synchronous methods freeze the thread, not necessarily the whole program.

Brattice

You're talking about sync and async in general and that too incorrectly. Async performs better in benchmarks in terms of total throughput. – Sunburn

Admittedly, I did make an assumption. Just to clarify, are you saying that several parallel asynchronous requests are better than several sequential synchronous requests? I'd believe that. How about for a single synchronous request versus a single asynchronous request? – Brattice

Yes I was talking about several in parallel. As for a single case there is no difference. – Sunburn

"whole program to freeze" is very inaccurate. Only the one thread is frozen while waiting, but hundreds of other threads are still active to process other HTTP requests. You're confusing windows gui threads and ASP.NET HTTP handling threads. – Listlessness

@Samuel, you're right. I'm approaching this from a single-threaded vs multi-threaded viewpoint, rather than async vs sync. – Brattice