Is async HttpClient from .Net 4.5 a bad choice for intensive load applications?

by

Besides the tests mentioned in the question, I recently created some new ones involving much fewer HTTP calls (5000 compared to 1 million previously) but on requests that took much longer to execute (500 milliseconds compared to around 1 millisecond previously). Both tester applications, the synchronously multithreaded one (based on HttpWebRequest) and asynchronous I/O one (based on HTTP client) produced similar results: about 10 seconds to execute using around 3% of the CPU and 30 MB of memory. The only difference between the two testers was that the multithreaded one used 310 threads to execute, while the asynchronous one just 22. So in an application that would have combined both I/O bound and CPU bound operations the asynchronous version would have produced better results because there would have been more CPU time available for the threads performing CPU operations, which are the ones that actually need it (threads waiting for I/O operations to complete are just wasting).

As a conclusion to my tests, asynchronous HTTP calls are not the best option when dealing with very fast requests. The reason behind that is that when running a task that contains an asynchronous I/O call, the thread on which the task is started is quit as soon the as the asynchronous call is made and the rest of the task is registered as a callback. Then, when the I/O operation completes, the callback is queued for execution on the first available thread. All this creates an overhead, which makes fast I/O operations to be more efficient when executed on the thread that started them.

Asynchronous HTTP calls are a good option when dealing with long or potentially long I/O operations because it doesn’t keep any threads busy on waiting for the I/O operations to complete. This decreases the overall number of threads used by an application allowing more CPU time to be spent by CPU bound operations. Furthermore, on applications that only allocate a limited number of threads (like it is the case with web applications), asynchronous I/O prevents thread pool thread depletion, which can happen if performing I/O calls synchronously.

So, async HttpClient is not a bottleneck for intensive load applications. It is just that by its nature it is not very well suited for very fast HTTP requests, instead it is ideal for long or potentially long ones, especially inside applications that only have a limited number of threads available. Also, it is a good practice to limit concurrency via ServicePointManager.DefaultConnectionLimit with a value that high enough to ensure a good level of parallelism, but low enough to prevent ephemeral port depletion. You can find more details on the tests and conclusions presented for this question here.

More Related Contents:

  1. HttpClient.GetAsync(…) never returns when using await/async
  2. awaitable Task based queue
  3. Async call with await in HttpClient never returns
  4. Using async / await with DataReader ? ( without middle buffers!)
  5. How to limit the amount of concurrent async I/O operations?
  6. C# HttpClient 4.5 multipart/form-data upload
  7. Async/await vs BackgroundWorker
  8. WaitAll vs WhenAll
  9. Running multiple async tasks and waiting for them all to complete
  10. Calling async method synchronously
  11. Entity Framework async operation takes ten times as long to complete
  12. Do you have to put Task.Run in a method to make it async?
  13. Task sequencing and re-entracy
  14. Calling async methods from a WCF service
  15. How to wait for async method to complete?
  16. How does Task become an int?
  17. Is async/await suitable for methods that are both IO and CPU bound?
  18. Why use async and return await, when you can return Task directly?
  19. async await return Task
  20. Executing tasks in parallel
  21. Proper way to start and fire-and-forget asynchronous calls?
  22. Use Task.Run() in synchronous method to avoid deadlock waiting on async method?
  23. A pattern for self-cancelling and restarting task
  24. A pattern to pause/resume an async task?
  25. How to Async Files.ReadAllLines and await for results?
  26. How do I create a custom SynchronizationContext so that all continuations can be processed by my own single-threaded event loop?
  27. Await vs Task.Result in an Async Method [duplicate]
  28. Async and Await with For Loop [duplicate]
  29. When is the best place to use Task.Result instead of awaiting Task
  30. Calling TaskCompletionSource.SetResult in a non blocking manner

Leave a Comment