3 ms·

I'd argue that Twitter and GitHub are excellent examples of where a CDN does not work. Some assets like logo's, headers, footers, css, fonts etc will improve g

by berkes 5y ago

I'd argue that Twitter and GitHub are excellent examples of where a CDN does not work. Some assets like logo's, headers, footers, css, fonts etc will improve greatly. But the main content is highly long-tail. And has a very high cache-miss chance. For 140 chars that's not going to matter. But all the images, videos, large source-codes, tarballs, builds, etc all add up. No CDN is going to help when a 30MB nightly build is only downloaded once ever. When a 2000line sourcefile is read maybe once a month. Or when a video in a tweet is seen by at most 2 followers ever.

acdha 5y ago
One other factor to consider: how much of your response latency is dominated by things like HTTPS session initialization or TCP window scaling? If a CDN means that the client does all of that within a few miles of the user and then their traffic to your origin server runs over the CDN provider's backbone, potentially with other backend optimizations like persistent connections and HTTPS session caching, it might actually be the case that it's faster than going direct for the users most like to experience performance problems. For a single download of a large file, yes, it's probably not going to matter since you're talking a percentage of the total file transfer time but the story can be different for something like a web page where the client makes a single connection and reuses it for everything rather than having to establish connections to multiple servers, wait for window scaling to kick in, etc.
- berkes 5y ago
  There are numerous reasons for employing a CDN. DDOS protection, for example, is another one. Many of those reasons will apply to long-tail content like GH of Twitter and offer benefits there. I was talking about the most obvious benefit of a CDN: caching on edge-servers.
  - acdha 5y ago
    Yes – my point was simply that caching connections (at any of the layers mentioned) is also often enough to be a net win even if the content cannot be cached.

by berkes 5y ago

acdha 5y ago

One other factor to consider: how much of your response latency is dominated by things like HTTPS session initialization or TCP window scaling? If a CDN means that the client does all of that within a few miles of the user and then their traffic to your origin server runs over the CDN provider's backbone, potentially with other backend optimizations like persistent connections and HTTPS session caching, it might actually be the case that it's faster than going direct for the users most like to experience performance problems. For a single download of a large file, yes, it's probably not going to matter since you're talking a percentage of the total file transfer time but the story can be different for something like a web page where the client makes a single connection and reuses it for everything rather than having to establish connections to multiple servers, wait for window scaling to kick in, etc.

berkes 5y ago
There are numerous reasons for employing a CDN. DDOS protection, for example, is another one. Many of those reasons will apply to long-tail content like GH of Twitter and offer benefits there. I was talking about the most obvious benefit of a CDN: caching on edge-servers.
- acdha 5y ago
  Yes – my point was simply that caching connections (at any of the layers mentioned) is also often enough to be a net win even if the content cannot be cached.