HttpClient shared instance with different sessions

Question

Context

The recommended way to use HttpClient is to create one instance and share it (according to the Microsoft documentation). There are many examples out there where using an HttpClient per request (on a server) yielded issues.

Problem

In my situation I have to run up to 20 simultaneous "sessions" which cannot interfere with one another. By "session" I mean isolated set of operations on a service or multiple services. No data should be shared between these sessions and specifically cookies.

These sessions are long lasting sessions (can last for days). But there may be only a maximum of 20 concurrent sessions at the same time. A slow start while instantiating these sessions is acceptable (up to 5 seconds).

Question

Should I use a pool? Should I reuse the same HttpClient instance? Should I spawn up to 20 HttpClients? Moreover, considering that they run concurrently, is it correct to assume that concurrent calls to a single HttpClient will be blocking?

Answer 1

The recommendation for creating only a single instance of HttpClient is because it creates a TCP connection that persists for a period of time. Eventually, it will get garbarge collected or closed naturally, but in the meantime, you could potentially exhaust the maximum amount of open connections on the server. There's also a bit of resource utilization from each connection that could prove problematic when stacked.

However, this is one of those things where there's no hard and fast rule. Certain things, like creating a new HttpClient per operation, are obviously problematic, but generally one instance per request to your server (not per request sent through HttpClient) shouldn't be problematic unless you're servicing a high number of concurrent requests.

You can also just make it a singleton across your application. HttpClient is not technically a user or session-specific thing. It would only be problematic if your changing default headers that should not be leaked across sessions. For example, you'd want to attach something like an Authorization header as part of creating a request, not as a default header when setting up the client. As long as you're smart about how you use it, there's no problem having it shared. That being "smart about how you use it" thing can sometimes be a point of failure, though. Even if you are, will the next developer be. More to the point, will they even know they should be? You might even forget, yourself.

Personally, I'd start making it request-scoped, where each request to your web application gets a separate instance, but that same instance will be used for all operations with HttpClient during that request. You can then do some profiling to see how the server is handling this, and if it does become a problem, then you can look for alternative solutions.