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

Question

I recently created a simple application for testing the HTTP call throughput that can be generated in an asynchronous manner vs a classical multithreaded approach.

T

Answer 1

While this does not directly answer the 'async' part of the OP's question, this addresses an error in the implementation he is using.

If you want your application to scale, avoid using instance-based HttpClients. The difference is HUGE! Depending on the load, you will see very different performance numbers. The HttpClient was designed to be re-used across requests. This was confirmed by guys on the BCL team who wrote it.

A recent project I had was to help a very large and well-known online computer retailer scale out for Black Friday/holiday traffic for some new systems. We ran into some performance issues around the usage of HttpClient. Since it implements IDisposable, the devs did what you would normally do by creating an instance and placing it inside of a using() statement. Once we started load testing the app brought the server to its knees - yes, the server not just the app. The reason is that every instance of HttpClient opens an I/O Completion Port on the server. Because of non-deterministic finalization of GC and the fact that you are working with computer resources that span across multiple OSI layers, closing network ports can take a while. In fact Windows OS itself can take up to 20 secs to close a port (per Microsoft). We were opening ports faster than they could be closed - server port exhaustion which hammered the CPU to 100%. My fix was to change the HttpClient to a static instance which solved the problem. Yes, it is a disposable resource, but any overhead is vastly outweighed by the difference in performance. I encourage you to do some load testing to see how your app behaves.

Also answered at link below:

What is the overhead of creating a new HttpClient per call in a WebAPI client?

https://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client