5 ms·

> Yes, there will be 200 ms RTT in some cases. So what? Get over it. You're missing a zero in that RTT for users in places like Asia if your server is anywher

by aseipp 5y ago

> Yes, there will be 200 ms RTT in some cases. So what? Get over it. You're missing a zero in that RTT for users in places like Asia if your server is anywhere in the west. (It's actually somewhat revealing when someone throws out a number like this without any qualification; what exactly made you conclude 200ms is the magic number?) > Optimize your website to load in fewer round-trips. TCP congestion control adapts well enough to any latency. RTT only really matters in gaming and VoIP. You don't need a very big imagination to think about cases where RTT will have significant impacts e.g. in the event you need to issue multiple sequential requests that are dependent on one another. 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.) This comes across as a classic "I don't actually understand the problem domain very well at all, but get off my lawn" answer to the problem.

grishka 5y ago
> 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 5y 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 5y 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 5y 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.

by aseipp 5y ago

grishka 5y ago

> 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 5y 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 5y 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 5y 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.