Search code examples
c#.nettcpdotnet-httpclient

How to disable pipelining for the .NET HttpClient

As the title says I'd like to disable the pipelining functionality BUT still make use of the connection pool (so KeepAlive=False is not an option). The reason is that longer requests may prevent shorter requests from executing fast, but opening up a new connection for every requests is significantly slower.

I'm doing this:

_webRequestHandler = new WebRequestHandler();
_webRequestHandler.AllowPipelining = false;

_httpClient = new HttpClient(_webRequestHandler);
await _httpClient.SendAsync(request);

servicePoint = ServicePointManager.FindServicePoint(request.RequestUri);

This seems to have no effect: The ServicePoint.SupportsPipelining property is still true and the WebRequestHandler is only setting the Pipelined property of the HttpWebRequest but nothing on the HttpRequestMessage so basically setting AllowPipelining on the WebRequestHandler has no effect (?).

Am I missing something here? I'm sure this is a common scenario - how can I achieve that?

Solution

  • The situation remains:

    • Setting ConnectionClose to true on the HttpClient issues a KeepAlive: false and establishes a new connection for every request. This has a significant negativ performance impact and is therefore undesired.
    • Setting ConnectionClose to false reuses the connections - but only when they are free (no pending request). Having a large number of simultanous requests will still open a large number of connections.
    • Setting the ConnectionLimit on the HttpClient to Environment.ProcessorCount * 12 (as suggested by MS) is limiting the number of open connections to the specified value. Unfortunately this is resulting in random unresponsiveness shutting the whole system down! I assume this happens when all open connections are used, pipelining is activated and then... something happens. This is why I wanted to turn pipelining off (just wait until any open connection becomes free and reuse it).

    But it seems this can not be set this way, at least I couldn't find it and no one could help me. And expecting MS to fix the real problem is... well, unlikely.

    So I ended up setting the ConnectionLimit to 1000 which seems to be high enough that the problem never occurrs (in our system). Not a real fix though - feel free to post if you have a better solution...