3 ms·

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.c

> You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. Well, it does say 130 ms in here: https://www.quora.com/How-long-would-it-take-for-light-to-fly-around-the-earth https://www.quora.com/How-long-would-it-take-for-light-to-fl... And that's around the planet, to go around and end up at the same spot. In practice, with sanely-configured routes, your packets should never need to traverse more than half that distance. So, divide it by 2, then that cancels out because RTT is a measure of how long it takes for a signal to travel back and forth. You then add some time on top of that to account for buffering and processing in the various equipment along the way. > These are unavoidable and occur often in more than just websites, but anything that e.g. uses HTTP as an API (a very simple one is something like recursively downloading dependencies.) If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? The request still needs to get to the server and the response still needs to come back, all the way, because that's where that code runs. CDNs only really work for cacheable static content, don't they? I mean it's in the name. A blog or a news website certainly doesn't need a CDN.

joshuamorton 6y ago
Of course, light doesn't travel at vacuum speed in fiber, it travels a bit slower, but it also bounces around the cable, so ends up traveling a significantly longer distance. Multiply by around 1.5 for more real world numbers (copper is similar), just measuring raw distance. And switching adds significant delay, especially when you get out to the edge. > If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? The request still needs to get to the server and the response still needs to come back, all the way, because that's where that code runs. CDNs only really work for cacheable static content, don't they? I mean it's in the name. For a simple example, imagine assets that are dynamically loaded based on feature detection in JS. All of the assets (js included) can be cached on the cdn.
bayindirh 6y ago
> Well, it does say 130 ms in here. If you have a fiber backed, all-switched network with no routing, buffers, congestions, or detours, you may get that value, if you're lucky. Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. I'm traversing a little less than half a globe with the whole journey. In your terms, it should be around ~60ms, but it's not. > If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? By using Cloudflare workers, so your code is also distributed around the globe? > CDNs only really work for cacheable static content, don't they? I mean it's in the name. JS files are also static content. Unless you don't use code distribution like Cloudflare workers, using a simple CDN can cache 90% of your site if not more. CSS, images, JS, HTML, you name it. > A blog or a news website certainly doesn't need a CDN. Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN?
- grishka 6y ago
  > Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. Actually I get around 200 from Russia which is also "somewhere between Europe and Asia": round-trip min/avg/max/stddev = 196.504/197.581/199.833/1.360 ms > By using Cloudflare workers, so your code is also distributed around the globe? Great, let's give that company even more control. That's sure gonna end well. > CSS, images, JS, HTML, you name it. It all gets loaded once and then cached in the browser. The initial load takes long regardless of whether there's a CDN. Oh, and many websites also use stuff from like 10 different domains, which doesn't help this either. And, it doesn't matter whether a JS file loads in 50 ms or 300 ms, if it then takes 5 seconds to parse and start running. > Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN? So put them on a separate domain and serve that from a CDN if you really care whether that stock photo no one notices loads in 500 ms instead of 2000. That doesn't explain much why anyone would put their main domain behind cloudflare.
  - bayindirh 6y ago
    > Great, let's give that company even more control. That's sure gonna end well. We have enough evil companies who invade our lives through the platform develop. Cloudflare is not one of them. Using them is voluntary (by the service providers), and I think they're one of the more useful companies around. BTW, I'm not a web developer or Cloudflare employee. I have no skin in this stuff, however they build some cool stuff inside the Linux kernel, which is interesting from my PoV. > It all gets loaded once and then cached in the browser. Then cleared and/or invalidated by the user or browser's logic itself due to plethora of reasons. > The initial load takes long regardless of whether there's a CDN. Actually, no. A reasonably fast internet connection (>12 Mbps we can say) can load a lot of things very very fast. The biggest overhead is DNS, even with CDNs. With a good local, network-wide DNSMasq installation, if the server is close, I can load big sites almost instantly. > And, it doesn't matter whether a JS file loads in 50 ms or 300 ms, if it then takes 5 seconds to parse and start running. I think 5 seconds is long time for even the old Netscape Navigator's JS parser. You need to run something akin skynet to parse the JS file for straight 5 seconds. How's that even possible? > So put them on a separate domain and serve that from a CDN if you really care whether that stock photo no one notices loads in 500 ms instead of 2000. I don't know you, but world news generally contains live/new footage or fresh photos from the ground, not some stock photos, also we humans are visual animals. Many people want to see the images first, read the text later. > That doesn't explain much why anyone would put their main domain behind cloudflare. Load balancing, DDoS protection, CDN, workers, Bot/Scraping protection, cost reduction, rate limiting, you name it. Even my DSL router implements some of the protections, to my surprise. Internet is not the same beast now when compared to 90s/00s. I miss the simpler times, but alas.
comex 6y ago
There's no need to guess based on the speed of light. Test it yourself: https://www.cloudping.info https://www.cloudping.info For me, the highest was 310ms round trip to Singapore, so higher than your estimate but not too bad. But this is completely beside the point. As far as I know, if you're using a CDN effectively (i.e. a large proportion of requests are hitting cache), it should be cheaper than having all requests hit your server, not more expensive. So even if you don't "need" a CDN, you might want one. This is orthogonal to the issue of bot traffic, which exists whether or not you use a CDN. If you want to use a CDN but don't mind the costs of bot traffic, you can configure CloudFlare to not show the CAPTCHAs, or use a different CDN.
- grishka 6y ago
  338 ms to Sydney is my worst. 234 ms to Singapore. AWS does offer a CDN, right? Somehow they do it without captchas and without me ever noticing. So I'm somewhat right at cursing at cloudflare because it's the only one actually announcing its presence by actively disrupting your browsing.
  - ehutch79 6y ago
    Cloudfront, the aws cdn, is not equivalent to the part that's showing a captcha. Only when it would have hit your server do you see the captcha, because it's proxying it, not serving cached results.
robocat 6y ago
I live in New Zealand, definitely a first world country with first world infrastructure. Ping times to US East or Europe are over 300ms right now from my home[1]. My old business had users in countries around the world, and the assets were highly optimised for speed. However adding CloudFlare (a) significantly sped up our service to clients, especially those in Asian countries, and (b) significantly improved reliability of connections because CloudFlare have their own dedicated network links between countries and/or optimised for reliability. [1] https://www.cloudping.info/ https://www.cloudping.info/
nijave 6y ago
Most end users are not in a position to control the path their packets take. Their ISP could route their packets around the world 6 times over if they can save a nickel doing it

joshuamorton 6y ago

Of course, light doesn't travel at vacuum speed in fiber, it travels a bit slower, but it also bounces around the cable, so ends up traveling a significantly longer distance. Multiply by around 1.5 for more real world numbers (copper is similar), just measuring raw distance. And switching adds significant delay, especially when you get out to the edge. > If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? The request still needs to get to the server and the response still needs to come back, all the way, because that's where that code runs. CDNs only really work for cacheable static content, don't they? I mean it's in the name. For a simple example, imagine assets that are dynamically loaded based on feature detection in JS. All of the assets (js included) can be cached on the cdn.

bayindirh 6y ago

> Well, it does say 130 ms in here. If you have a fiber backed, all-switched network with no routing, buffers, congestions, or detours, you may get that value, if you're lucky. Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. I'm traversing a little less than half a globe with the whole journey. In your terms, it should be around ~60ms, but it's not. > If you mean REST API requests, the kind that trigger some code to dynamically generate a response, how would a CDN solution like cloudflare help? By using Cloudflare workers, so your code is also distributed around the globe? > CDNs only really work for cacheable static content, don't they? I mean it's in the name. JS files are also static content. Unless you don't use code distribution like Cloudflare workers, using a simple CDN can cache 90% of your site if not more. CSS, images, JS, HTML, you name it. > A blog or a news website certainly doesn't need a CDN. Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN?

grishka 6y ago
> Pinging tty.sdf.org which is a direct access shell service in USA from somewhere between Europe and Asia, from an academic network backbone roundtrips in ~190ms. Actually I get around 200 from Russia which is also "somewhere between Europe and Asia": round-trip min/avg/max/stddev = 196.504/197.581/199.833/1.360 ms > By using Cloudflare workers, so your code is also distributed around the globe? Great, let's give that company even more control. That's sure gonna end well. > CSS, images, JS, HTML, you name it. It all gets loaded once and then cached in the browser. The initial load takes long regardless of whether there's a CDN. Oh, and many websites also use stuff from like 10 different domains, which doesn't help this either. And, it doesn't matter whether a JS file loads in 50 ms or 300 ms, if it then takes 5 seconds to parse and start running. > Actually, CDN is the most basic optimization for distributing heavy assets like videos and images, which news websites use way more than text. Why not use a CDN? So put them on a separate domain and serve that from a CDN if you really care whether that stock photo no one notices loads in 500 ms instead of 2000. That doesn't explain much why anyone would put their main domain behind cloudflare.
- bayindirh 6y ago
  > Great, let's give that company even more control. That's sure gonna end well. We have enough evil companies who invade our lives through the platform develop. Cloudflare is not one of them. Using them is voluntary (by the service providers), and I think they're one of the more useful companies around. BTW, I'm not a web developer or Cloudflare employee. I have no skin in this stuff, however they build some cool stuff inside the Linux kernel, which is interesting from my PoV. > It all gets loaded once and then cached in the browser. Then cleared and/or invalidated by the user or browser's logic itself due to plethora of reasons. > The initial load takes long regardless of whether there's a CDN. Actually, no. A reasonably fast internet connection (>12 Mbps we can say) can load a lot of things very very fast. The biggest overhead is DNS, even with CDNs. With a good local, network-wide DNSMasq installation, if the server is close, I can load big sites almost instantly. > And, it doesn't matter whether a JS file loads in 50 ms or 300 ms, if it then takes 5 seconds to parse and start running. I think 5 seconds is long time for even the old Netscape Navigator's JS parser. You need to run something akin skynet to parse the JS file for straight 5 seconds. How's that even possible? > So put them on a separate domain and serve that from a CDN if you really care whether that stock photo no one notices loads in 500 ms instead of 2000. I don't know you, but world news generally contains live/new footage or fresh photos from the ground, not some stock photos, also we humans are visual animals. Many people want to see the images first, read the text later. > That doesn't explain much why anyone would put their main domain behind cloudflare. Load balancing, DDoS protection, CDN, workers, Bot/Scraping protection, cost reduction, rate limiting, you name it. Even my DSL router implements some of the protections, to my surprise. Internet is not the same beast now when compared to 90s/00s. I miss the simpler times, but alas.

comex 6y ago

There's no need to guess based on the speed of light. Test it yourself: https://www.cloudping.info https://www.cloudping.info For me, the highest was 310ms round trip to Singapore, so higher than your estimate but not too bad. But this is completely beside the point. As far as I know, if you're using a CDN effectively (i.e. a large proportion of requests are hitting cache), it should be cheaper than having all requests hit your server, not more expensive. So even if you don't "need" a CDN, you might want one. This is orthogonal to the issue of bot traffic, which exists whether or not you use a CDN. If you want to use a CDN but don't mind the costs of bot traffic, you can configure CloudFlare to not show the CAPTCHAs, or use a different CDN.

grishka 6y ago
338 ms to Sydney is my worst. 234 ms to Singapore. AWS does offer a CDN, right? Somehow they do it without captchas and without me ever noticing. So I'm somewhat right at cursing at cloudflare because it's the only one actually announcing its presence by actively disrupting your browsing.
- ehutch79 6y ago
  Cloudfront, the aws cdn, is not equivalent to the part that's showing a captcha. Only when it would have hit your server do you see the captcha, because it's proxying it, not serving cached results.

robocat 6y ago

I live in New Zealand, definitely a first world country with first world infrastructure. Ping times to US East or Europe are over 300ms right now from my home[1]. My old business had users in countries around the world, and the assets were highly optimised for speed. However adding CloudFlare (a) significantly sped up our service to clients, especially those in Asian countries, and (b) significantly improved reliability of connections because CloudFlare have their own dedicated network links between countries and/or optimised for reliability. [1] https://www.cloudping.info/ https://www.cloudping.info/

nijave 6y ago

Most end users are not in a position to control the path their packets take. Their ISP could route their packets around the world 6 times over if they can save a nickel doing it