Ditto for me in UK. it's been fine for the past two days.
S.
S.
-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Slow and laggy forum?
- Thread starter TimoJ
- Start date
audio_tony
Major Contributor
I've also had issues on and off (I'm UK based) - so I setup a monitor.
NOTE: this pulls a single page every 45 minutes so it's not loading the server in any way.
I hope to build up a useful pattern if issues prevail.
NOTE: this pulls a single page every 45 minutes so it's not loading the server in any way.
I hope to build up a useful pattern if issues prevail.
I've found image downloading to be very slow here for months. I don' think the problem is on my end; my download speed here per Speedtest.net is >900 Mbps.
- Joined
- Jun 24, 2024
- Messages
- 3,170
- Likes
- 5,829
Would seem to indicate it has something to do with the route being used. Possibly some edge provider is throttling the traffic or some other kind of shenanigans.
Gone very slow again, but varies. One time it's very slow, a few minutes later, perhaps even less, it's normal.
Very frustrating.
S.
Very frustrating.
S.
It's timed out completely for me a couple of times the last few weeks. Also just now:
audio_tony
Major Contributor
I just had a really slow page load, so I refreshed my monitoring a few times, but it revealed nothing!
I also immediately tried another browser, one that I've not used for ASR previously - and there was a lag there as well, although not as bad.
It's been quite stable over the past 24 hours as well.
I also immediately tried another browser, one that I've not used for ASR previously - and there was a lag there as well, although not as bad.
It's been quite stable over the past 24 hours as well.
Unfortunately, it’s lagging on and off now. I’ve been testing it over the last few hours. Sometimes I can’t even access ASR.
I have spent hours trying to toubleshoot and deploy different solutions. None of it easy. Trying to for example cache the images by Cloudflare, only to find out that our platform specifically marks images as "no cache." 
Getting around that requires code and using cloudflare R2 features. Latter seems to be a pay as you go.
The challenge is that I can't allocate the time to debug such deep IT related things. If someone has expertise and wants to offer it, that would be great.
Getting around that requires code and using cloudflare R2 features. Latter seems to be a pay as you go.The challenge is that I can't allocate the time to debug such deep IT related things. If someone has expertise and wants to offer it, that would be great.
OK, I just disabled Cloudflare. Please report if the problem is still there.
TLS certificate is broken now it seems.
Nowadays validities are relatively shorts this one is valid until 2034… and it’s missing (part of) the chain.
Very strange. As soon as I pause Cloudflare, it causes those and other issues. So that is not a workable option. It is back on.
OK, I opened a ticket with my platform provider (digital ocean). Their support is awful but let's see what they say in 24 hours. I am fairly certain the problem is at the end seeing how performance is excellent in US. Indeed, faster than I have ever seen it!
The server is in San Francisco which is a bad choice for EU members to begin with. But it has been at this location from day one so something is wrong.
OK, I opened a ticket with my platform provider (digital ocean). Their support is awful but let's see what they say in 24 hours. I am fairly certain the problem is at the end seeing how performance is excellent in US. Indeed, faster than I have ever seen it!
The server is in San Francisco which is a bad choice for EU members to begin with. But it has been at this location from day one so something is wrong.
danadam
Major Contributor
- Joined
- Jan 20, 2017
- Messages
- 1,666
- Likes
- 2,576
AFAICT this is the certificate intended for communication between Cloudfare and the origin web server. It's not intended for communication with browsers.
Oh, it's fixed now.
audio_tony
Major Contributor
@amirm
I've done some testing from the UK and set up a monitor which is polling the forum every 45 minutes.
Requests are normally reaching Cloudflare's London (LHR) edge, so European users aren't being routed all the way to San Francisco just to reach Cloudflare.
What looks interesting is the time spent waiting for responses. For example, with Chrome's local cache disabled, the forum loads six CSS resources ranging from only 0.7 kB to 34.5 kB. They all take roughly 186–203 ms, almost regardless of size. Looking at Chrome's detailed timings, around 180–190 ms is spent waiting for the first byte; the actual download takes less than 1 ms for the small files.
Those CSS requests all report:
CF-Cache-Status: DYNAMIC
despite the server returning:
Cache-Control: public, max-age=31536000
and they're being served via Cloudflare LHR. So Cloudflare isn't serving those particular resources as normal edge-cache HITs. It may be worth asking DigitalOcean/Cloudflare why the versioned css.php resources are being treated as dynamic despite the one-year public cache header.
The main forum page shows a similar pattern. My UK monitor is seeing roughly 0.3–0.9 seconds TTFB, while the actual HTML transfer after the first byte is relatively quick. So most of the variation appears to be waiting for the response rather than bandwidth/download speed.
I also happened to catch the period when you paused Cloudflare. Before that, my monitor was receiving HTTP 200 with CF-Ray: ...-LHR. Once Cloudflare was paused, public DNS changed to 143.110.158.227, which appears to be the DigitalOcean origin. That server presents a Cloudflare Origin CA certificate, so direct HTTPS clients reject it as untrusted. That explains the failures you saw when Cloudflare was paused; it doesn't look like evidence of the original performance problem.
I don't think this proves yet whether the delay is Cloudflare, the transatlantic Cloudflare→origin path, or processing at the DigitalOcean server, but it does seem to narrow the issue down considerably. The client→Cloudflare London side looks healthy; most of the measurable delay is after the request has been sent and before the first response byte arrives.
I put this all into AI and the attached pdf is a short summary of potential actions / pitfalls.
I've done some testing from the UK and set up a monitor which is polling the forum every 45 minutes.
Requests are normally reaching Cloudflare's London (LHR) edge, so European users aren't being routed all the way to San Francisco just to reach Cloudflare.
What looks interesting is the time spent waiting for responses. For example, with Chrome's local cache disabled, the forum loads six CSS resources ranging from only 0.7 kB to 34.5 kB. They all take roughly 186–203 ms, almost regardless of size. Looking at Chrome's detailed timings, around 180–190 ms is spent waiting for the first byte; the actual download takes less than 1 ms for the small files.
Those CSS requests all report:
CF-Cache-Status: DYNAMIC
despite the server returning:
Cache-Control: public, max-age=31536000
and they're being served via Cloudflare LHR. So Cloudflare isn't serving those particular resources as normal edge-cache HITs. It may be worth asking DigitalOcean/Cloudflare why the versioned css.php resources are being treated as dynamic despite the one-year public cache header.
The main forum page shows a similar pattern. My UK monitor is seeing roughly 0.3–0.9 seconds TTFB, while the actual HTML transfer after the first byte is relatively quick. So most of the variation appears to be waiting for the response rather than bandwidth/download speed.
I also happened to catch the period when you paused Cloudflare. Before that, my monitor was receiving HTTP 200 with CF-Ray: ...-LHR. Once Cloudflare was paused, public DNS changed to 143.110.158.227, which appears to be the DigitalOcean origin. That server presents a Cloudflare Origin CA certificate, so direct HTTPS clients reject it as untrusted. That explains the failures you saw when Cloudflare was paused; it doesn't look like evidence of the original performance problem.
I don't think this proves yet whether the delay is Cloudflare, the transatlantic Cloudflare→origin path, or processing at the DigitalOcean server, but it does seem to narrow the issue down considerably. The client→Cloudflare London side looks healthy; most of the measurable delay is after the request has been sent and before the first response byte arrives.
I put this all into AI and the attached pdf is a short summary of potential actions / pitfalls.
Thanks. I had forgotten that the certificates are on Cloudflare so pausing that, caused the connection to not be secure. So I turned it back on.
Between Cloudflare and DigitalOcean, I definitely trust the former more. I suspect when Cloudflare LHR is contacting Digital Ocean, that connection is busted. Hopefully I get a competent support person that can diagnose this.
Between Cloudflare and DigitalOcean, I definitely trust the former more. I suspect when Cloudflare LHR is contacting Digital Ocean, that connection is busted. Hopefully I get a competent support person that can diagnose this.