thank you, zehawki. I passed that on, and it looks like we will get a chance to talk about this in more detail soon. Keep the request IDs coming I’d say, and we will definitely let you know as we figure out more information. thanks for your patience.
I hit another massive slowdown (or outage) today a while ago, across sites, with sites not loading. Lasted for about ~2 mins.
Started with this:
timestamp with timezone
13/02/22, around 12:30GMT (Once again, apologies, next time I’ll record precise TS)
complete URL
MainCross Social+
status
404 on the js chunk
And then I tried to reload this site and load others that are on Netlify - but nothing was loading. Then just as suddenly, all OK.
PS: Please note that whenever I hit this issue on Netlify, I immediately crosscheck vs our instances on Cloudflare (eg https://www.dhanada.in, https://www.hoten.life) to be sure that its not across the board.
Thank you so much for providing this additional information! We shared it on the issue where we are tracking this.
1 Like
hi there zehawki, we didn’t forget and i am trying to get an update for you.
1 Like
And we are back.
I certainly hear Netlify when it says that all these troubles happen for “sites that are not in cache”, ie they are not busy enough. So do we have to live with this? And how quickly are assets moving out of cache - are they getting dropped every 30 seconds?? Why only certain assets, and not all? Very mysterious.
x-nf-request-id: 01G0VXEKC41XE8K5F580PEPAKF
Note that the above was after reloading the same site for the 4th time. Should certainly be in cache by then or?
This is the first:
x-nf-request-id: 01G0VX8M4CVF7B9J2Y9WDVAGSP
x-nf-request-id: 01G0VX8M4DVXJT0RT12HN670CT
Similar delays seen on load 2 and load 3.
So this part is rather frustrating. I really don’t see any reason why hashed static resources that are already in browser cache should have max-age=0 and then end up with such grand delays.
More (another site):
x-nf-request-id: 01G0VXWW4HVYF6YVBC454HB4FR
Thank you for reaching back out to us on this! The engineering team is still investigating, so the additional request IDs and info you’ve provided will be very helpful as they continue to research. I’m sending this over to them now, and I will follow up with you as soon as I receive word back from the engineering team.
We’re also noticing extremely slow download times, randomly.
For instance x-nf-request-id: 01G3YVPS40833YNGR4J2CTYER7, downloaded a 1.3mb bundle in 44s.
Is there a setting we need to adjust on our end? Thank you.
Hi, @ldiqual. Thank you for sharing that x-nf-request-id. I see the same thing in our logs. I’ve written up an analysis of the slow HTTP responses for your sites and escalated this to our developers to take a look at this.
Once we have a response from our developers, will post another update here to let you know what we discover.
1 Like
Thanks for your patience while we reviewed in more details, @ldiqual !
I do see exactly 43 requests that took over 5 seconds, over the course of the week 24 May to 31 May across all sites within your account. Those were exactly .02% of your total traffic, and some of them were fairly large (2-3MByte) assets which we would expect it to occasionally take over 5 seconds to send while our CDN is working normally - for instance to a slow client, or if the asset is not cached on the CDN node the client connected to. Our CDN has dozens of nodes, so to answer your question:
Note that the above was after reloading the same site for the 4th time. Should certainly be in cache by then or?
No, it might not be. Each CDN node maintains its own cache and we usually have around a dozen in our points of presence, so even the 12th reload for the same browser from the same location in the same 5 minutes, may still be bringing an asset into cache.
In short, while I do agree that the occasional slow loads aren’t ideal, our CDN is behaving within the parameters we intend, in aggregate. Or, put another way, since it is such a small percentage of requests, we will not be able to investigate more deeply in this case. I do recommend reading this article about using forever-changing names in your javascript files, which could help the assets be more cacheable across deploys, though: [Support Guide] Making the most of Netlify's CDN cache
I also didn’t see anyone respond to you directly about “was there some misconfiguration here?” and I do not see anything that seems wrong or that I would improve in your configuration (besides not changing filenames when content doesn’t change, per the article I linked above, to improve cacheability).
So, while I understand this isn’t the answer you wanted, we aren’t saying we’ll never investigate again. But in this case, the incidence is so low across your account, that we will not be able to investigate this incidence further, unless it happens rather more frequently.