You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks. Right now it doesn't happen, but the page also opens quickly. I'm guessing, when it happens, something is running slow, and I'm not sure an increased timeout would be a proper solution in that case.
Last time it happened was when I reported this bug, a few minutes earlier.
Something similar to this was also reported when the site was launched, and a fix was put in. @GregKaleka can you also keep an eye on this if it keeps happening?
I think Rob is referring to #1798. The fix for that was related to parsing html from a documentation file, which the libraries list definitely does not do, so the fix would not be the same.
@Lastique , yesterday I enabled "Shielding" on the CDN, which routes all requests through one datacenter to increase the HIT ratio. Overall, statistics improved. And, there was not a drop-off of traffic. But you are reporting a problem.
I have now just switched the shield location from Chicago to Ashburn. If you enabled Developer Tools on the browser, the relevant fields are X-Cache, X-Served-By,
Activity
sdarwin commentedon May 28, 2025
I have increased the 'first byte timeout' from 15 seconds to 60 seconds.
Please report if the problem continues.
sdarwin commentedon May 28, 2025
Also, for the next occurrence, it could help to send the exact time it happened. (and timezone. or UTC).
Lastique commentedon May 28, 2025
Thanks. Right now it doesn't happen, but the page also opens quickly. I'm guessing, when it happens, something is running slow, and I'm not sure an increased timeout would be a proper solution in that case.
Last time it happened was when I reported this bug, a few minutes earlier.
rbbeeston commentedon May 28, 2025
Something similar to this was also reported when the site was launched, and a fix was put in. @GregKaleka can you also keep an eye on this if it keeps happening?
GregKaleka commentedon May 28, 2025
I think Rob is referring to #1798. The fix for that was related to parsing html from a documentation file, which the libraries list definitely does not do, so the fix would not be the same.
I'll definitely keep an eye on this.
sdarwin commentedon May 28, 2025
In the screenshot "cache-fra" is Frankfurt. And then, even a further network trip to Andrey. Could be packet loss. Although not certain.
Lastique commentedon Jun 14, 2025
Now the website seems to be completely down. I get "stream timeout" or "upstream request timeout" with no further details.
sdarwin commentedon Jun 14, 2025
@Lastique , yesterday I enabled "Shielding" on the CDN, which routes all requests through one datacenter to increase the HIT ratio. Overall, statistics improved. And, there was not a drop-off of traffic. But you are reporting a problem.
I have now just switched the shield location from Chicago to Ashburn. If you enabled Developer Tools on the browser, the relevant fields are X-Cache, X-Served-By,
Lastique commentedon Jun 14, 2025
Right now the website is accessible again. The response e.g. for
styles.css
is:sdarwin commentedon Jun 14, 2025
That's good. There is a real lag in their configuration, cache-chi is still Chicago, cache-iad is Ashburn. I'm getting
x-served-by cache-iad-kcgs7200030-IAD, cache-den-kden1300080-DEN
Or maybe FRA (Frankfurt) is serving a cache hit and it still remembers that is from CHI (Chicago). yes.