DefaultHTTPClientProvider/DefaultHTTPClient implementation can cause socket exhaustion
Describe the bug https://github.com/segmentio/Analytics-CSharp/blob/4fe89cbe9855b84203d5a85f29bce55bdb84b02f/Analytics-CSharp/Segment/Analytics/Utilities/HTTPClient.cs#L181
The DefaultHTTPClientProvider/DefaultHTTPClient implementation is improperly using HttpClient.
When using Analytics as scoped, it ends up with a call to "new HttpClient(.." on every request, which is known to cause issues.
HttpClient is intended to be instantiated once and reused throughout the life of an application. In .NET Core and .NET 5+, HttpClient pools connections inside the handler instance and reuses a connection across multiple requests. If you instantiate an HttpClient class for every request, the number of sockets available under heavy loads will be exhausted. This exhaustion will result in SocketException errors. https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-net-http-httpclient
To Reproduce Steps to reproduce the behavior:
- make a ton of requests to Analytics when it's registered as scoped
Expected behavior open sockets do not spike
Screenshots If applicable, add screenshots to help explain your problem.
here's a view of what happens to open sockets when a burst of requests happen.
Platform (please complete the following information):
- Library Version in use: 2.x
Additional context I also have concerns over how the setings are instantiated. https://github.com/segmentio/Analytics-CSharp/blob/4fe89cbe9855b84203d5a85f29bce55bdb84b02f/Analytics-CSharp/Segment/Analytics/Analytics.cs#L243 all of which can be fixed by properly following http client best practices. https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines
hi @bcrispcvna, thanks for reporting this issue. we are working on some optimizations for server use cases. in the meanwhile, you can create your own httpclient and pass it to configuration as a workaround. also be aware of some other implications if you want to use this SDK as scoped for server use cases.
@wenxi-zeng
Does this potential exhaustion also occur with a singleton approach? Just curious if I should wait for this fix before moving forward with the migration from the older SDK.
hi @richerm, no, singleton does no have this issue.