-
Notifications
You must be signed in to change notification settings - Fork 644
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
[NuGet.org Bug]: api.nuget.org is slow from some geographic locations #9308
Comments
Hey @mjolka, thanks for the detailed report. tl;dr: this is a known issue but we don't have a date we can share of when it will be improved. That being said, on the client side, we've increase parallelism in VS per NuGet/Home#11923 (which I see you've also originally posted, thank you for the focus on performance!). This is a known issue primarily affecting the performance of the Package Manager UI, as you've stated. There are other JSON endpoints with the same symptom you're seeing (slower latency across geos) but, based on end-to-end performance tests (e.g. total Generally speaking, for the "api.nuget.org" domain, we have a variety of caching mechanisms and several geographic locations backing the CDN nodes which serve requests. For example, we have a dedicated storage CDN and storage backend in China yielding superior performance in this case. The "https://api.nuget.org/v3/index.json" URL is highly cached at the CDN level which is why the performance is good across geos. Similarly, .nupkg and .nuspec URLs are highly cached too. We've been unable to cache JSON endpoints in most cases due to concerns about data consistency across multiple URLs that the client interacts with in a session but it's an area we're experimenting with for both performance and availability reasons. I don't have an ETA for you, however. For the particular user scenario of the Browse tab in the PM UI, we have #7297 planned which will alleviate the need for so many HTTP requests, thus reducing the impact of lower latency across geos. Unfortunately, this work will not help the Installed or Updates tab which need to pull information about a set of IDs known only to the client (compared to the Browse tab where the set of IDs is provided by the server). Thanks for the high-quality issue report. I'll leave this issue open since it is indeed a problem but I can't provide you a timeline of when it will get better. |
This is still a problem. from Bangkok |
@joelverhagen has there been any movement on the CDN being slow in certain regions? I'm seeing unreasonable slowness in the UK getting this package: It's also like the first 8mb has been cached (by my previous attempts) but the remainder is coming at 15kb/s with pauses. I'm up to 9mb now, but you can imagine how long this has taken. Other files didn't appear to have the same issue when I installed syncfusion.blazor.inputs, presumably due to smaller sizes. |
Hi! @tyeth My apologies for the inconvenience! Multiple customers reported that CDN is slow in UK. We have switched the traffic to another CDN service. Feel free to reach out to support (https://www.nuget.org/policies/Contact) if the issue is still ongoing. |
Impact
It's more difficult to complete my work
Describe the bug
api.nuget.org is slow from some geographic locations, including where I'm based (Australia).
To test this, I created DigitalOcean Droplets in different regions and ran tests using ApacheBench.
This table shows the time taken to complete 100 requests for a resource on api.nuget.org, using HTTP Keep Alive.
When using NuGet Package Manager UI, the Updates and Installed tabs can make several hundred API requests. This combined with the slow response time degrades the user experience for people in certain locations.
From my home machine, I'm seeing times comparable to Singapore in the table above.
Detailed results:
New York
San Francisco
London
Singapore
Repro Steps
Expected Behavior
Response times should not vary so dramatically with geographic location.
Screenshots
No response
Additional Context and logs
After further testing, I found that this does not apply to https://api.nuget.org/v3/index.json.
For
/v3/index.json
, theServer
response header value (ECAcc (mbw/47ED)
) shows that it is being served from an Edgio PoP, while for other requests the value isWindows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
.The text was updated successfully, but these errors were encountered: