Best practice usage of HttpClient for REST calls maximum throughput RRS feed

  • Question

  • I'm trying to gain some clarity on the behavior of HttpClient and the best practice usage when making calls to a REST service.


    As far as I can tell from the source, the ServicePoint.DefaultConnectionLimit (Default of 2 connections per host) is circumvented by assigning a ConnectionGroupName to each HttpClientHandler.

    However, also as far as I can tell by looking at the source, each HttpClient instance composes on HttpMessageHandler instance, which would mean that if HttpClient is shared in a concurrent environment, such a limit would still apply.

    This makes me think that the optimal usage of HttpClient is to create a new instance on each usage and dispose it immediately afterwards. Is this correct in terms of network performance? If so, how does this weigh against the construction cost of the object?

    Finally, given that the calls are to one REST service only, what is the best way to use KeepAlive/UnsafeAuthenticatedConnectionSharing?


    Wednesday, May 2, 2012 11:35 AM

All replies

  • Georgios,

    Think of an HttpClient instance is a kind of "session" which share configuration options as well as underlying TCP connections. If you have requests that are related (or won't step on eachother) then using the same HttpClient makes a lot of sense. It will help reuse TCP connections where possible which will in general lead to better performance.

    Everytime you create a new HttpClient you start a new session meaning that new TCP connections will have to get created etc.

    In genral I would recommend reusing HttpClient instances as much as possible.


    Henrik Frystyk Nielsen

    Wednesday, May 2, 2012 2:59 PM
  • Thanks, that makes sense.

    Could you please elaborate on any configuration options that would improve performance on certain scenarios?

    Wednesday, May 2, 2012 5:05 PM
  • Is HttpClient Thread Safe? In the interest of reusing connections I'd like to use as few HttpClient objects as possible. Is it OK to have just one that I call GetAsync() on concurrently from multiple threads?
    Monday, July 9, 2012 2:54 AM
  • When running HttpClient.PostAsync in a Parallel.For it will not post unique messages. In my test program it always took the message from the last call.

    Something like this:

    Parallel.For(0, 5, i => {

    var id = Guid.NewGuid();


    client.PostAsync(url, id);


    Console always printed different guids but the controller action always got the same guid. If I changed it from Parallel.For to a sequential 'for' it worked.

    Does that mean that we shouldn't reuse HttpClient for Posts?

    Saturday, July 14, 2012 8:18 PM
  • Anyone?
    Monday, August 6, 2012 8:16 AM
  • Can you use HttpListener to create a standalone replica of the problem? We could then look into it.
    Tuesday, August 7, 2012 3:57 PM
  • According to the documentation: "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."


    Tuesday, October 16, 2012 10:15 PM