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

One thing to consider that might be affecting your results is that with the HttpWebRequest you are not getting the ResponseStream and consuming that stream. With HttpClient, by default it will copy the network stream into a memory stream. In order to use HttpClient in the same way that you are currently using HttpWebRquest you would need to do

var requestMessage = new HttpRequestMessage() {RequestUri = URL};
Task getTask = httpClient.SendAsync(requestMessage, HttpCompletionOption.ResponseHeadersRead);

The other thing is that I'm not really sure what the real difference, from a threading perspective, you are actually testing. If you dig into the depths of HttpClientHandler it simply does Task.Factory.StartNew in order to perform an async request. The threading behaviour is delegated to the synchronization context in exactly the same way as your example with HttpWebRequest example is done.

Undoubtedly, HttpClient add some overhead as by default it uses HttpWebRequest as its transport library. So you will always be able to get better perf with a HttpWebRequest directly whilst using HttpClientHandler. The benefits that HttpClient brings is with the standard classes like HttpResponseMessage, HttpRequestMessage, HttpContent and all the strongly typed headers. In itself it is not a perf optimization.