-
Notifications
You must be signed in to change notification settings - Fork 859
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the reason for keeping HttpClientCacheSize to number Environment.ProcessorCount on Linux #1929
Comments
Hi @madhub, Good morning. Thanks for posting the guidance question. Looking at the documentation comment for While we cannot advise if you should set Thanks, |
Thanks for the response, .NET Core 2.1 on wards implementation is same for Windows & Non Windows platforms .See the documentation here HttpClient Sockets improvements. .NET Core 2.1 Release More information about how HttpClient internal implemented before .NET Core 2.1 and after 2.x |
@madhub when this code was written .NET Core was using a different implementation for windows and linux. We do need to revise this code now that both platforms use I suspect you are right and we should just use one cached HttpClient with the modern versions of .NET Core. We will need to do some validation first before making that change. |
Note that HttpClient uses |
We got bitten by this exact issue, combined with our use of the new It would be good to get this fixed in the SDK @normj. |
I was also just bit by this when testing on Linux. Requests under 1 MB went from taking almost 200 ms to finish GetObjectAsync and another 200 to execute CopyToAsync to 50ms round trip. This is a pretty large difference even for a simple example. |
Why hasn't this value been streamlined? I mean we are now alread in .NET 8 preview mode, which will be the next LTS and all of what has been written here in this issue is valid for multiple years now. |
See #2549 |
Closing issue since PR #2549 is merged and released per #2549 (comment). |
|
The Question
Currently we are investigating slowness of S3 access on Linux deployment, upon investigation we found number of cache HttpClient varies between Windows & Linux relevant section of the code is ClientConfig.cs
What is the reason of having different number for cached HttpClients ?
From .NET Core 2.1 onwards HttpClient uses SocketsHttpHandler on both Windows & Linux and their should not be any behavior changes.
Here is the sample scenario to show the difference
On 10 CPU systems make 10 S3 request to same object on the same bucket.
So should we set the
AmazonS3Config.HttpClientCacheSize
to 1 on Linux ? , any recommendation ?Environment
dotnet
This is a ❓ general question
The text was updated successfully, but these errors were encountered: