3 ms·

There is actually weird magic around keeping open tcp sessions open so you could be faster if close to a cloudflare node and distant to the server, too, even if

by rdl 10y ago

There is actually weird magic around keeping open tcp sessions open so you could be faster if close to a cloudflare node and distant to the server, too, even if not cached.

saurik 10y ago
The issue with CloudFlare here is that they never really cared to be a good "normal CDN", which would make this performance boost possible by using a combination of intelligent caching and an extremely large number of POPs using good trunks; see Akamai or CDNetworks for typical examples of trying to actually play the game of a normal CDN. Instead, CloudFlare relies on crazy content transforms that started as essentially "what if we run mod_pagespeed for you in the cloud as a service" and then expanded in scope from there. I mean, even when they cache things, as I understand it their cache hit ratio is extremely poor (whether due to restrictive cache sizes or limited retention windows, I don't even venture to guess). This means that if your content isn't inherently slow (using poorly compressed images and tons of fragmented JavaScript and CSS files with broken ETags being consumed by HTML with script tags in "the wrong places", none of which is minified), CloudFlare is going to make your site slower. Really: the two things they ended up getting stuck in the ecosystem for were 1) being free or at a fixed low price for supposedly infinite bandwidth (though people report that when you actually use a ton, CloudFlare claims you are being attacked and need to upgrade to their protection racket, which leads us to), and 2) performing DoS attack protection by using a ton of annoying heuristics and IP filters and JavaScript delays and even captchas that you should notice no "real" site behind a normal CDN ever seems to need, and yet somehow is a hallmark of the experience of "this site is using CloudFlare".
- acdha 10y ago
  I've done a fair bit of testing and while their cache rate wasn't as high as Akamai, it wasn't as bad as you're making it sound: something like 50% vs. 60%. One of the challenges here is popularity: if you're a major site, yes, Akamai will have content cached at most of those 140k POPs but sites with different blends of cacheability and global traffic distribution might see a better cache hit ratio with fewer POPs so things stay hot in the cache longer. These are complicated services so the results are going to bay widely depending on what you need (e.g. having an optimized site means that every optimizer service I've tried made performance worse), and how much you can adjust your application to work with the CDN and tech changes like HTTP/2. The other reason why blanket statements aren't worth the time needed to make them is that these are not free services and you can get easily find cases where service A is better than service B but not enough so to justify the price. (Add for the DoS tools, note that that's pronounced “feature” by most people and at least personally I never see them except when testing through a commercial hosting company's network. Tor users whine a lot about them but that's just entitlement and unwillingness to think critically about what a site owner sees from their peers.)
  - saurik 10y ago
    FWIW, I'm used to seeing >95% from working with CDNetworks (and I believe that's even in their literature somewhere), which has a kind of (to borrow a term from a different kind of service) "supernode"-like model for their cache layer, proactively distributes cached resources, and does revalidation as a separate path from fetches. As for their DoS "features", yes: they have a bunch of features because it makes them look like they are doing something worth value, but I am going to again remind you that somehow you never see websites that are using normal CDNs suddenly give up and give you an Akamai-branded captcha, and yet somehow they do not crumble under the weight of denial of service attacks; it just isn't the case that using CloudFlare is the only way to be safe from DDoS, and there's something weird about how the experience of using a CloudFlare website somehow is noticable.
  - deleted 10y ago
    [deleted]

by rdl 10y ago

There is actually weird magic around keeping open tcp sessions open so you could be faster if close to a cloudflare node and distant to the server, too, even if not cached.

saurik 10y ago

The issue with CloudFlare here is that they never really cared to be a good "normal CDN", which would make this performance boost possible by using a combination of intelligent caching and an extremely large number of POPs using good trunks; see Akamai or CDNetworks for typical examples of trying to actually play the game of a normal CDN. Instead, CloudFlare relies on crazy content transforms that started as essentially "what if we run mod_pagespeed for you in the cloud as a service" and then expanded in scope from there. I mean, even when they cache things, as I understand it their cache hit ratio is extremely poor (whether due to restrictive cache sizes or limited retention windows, I don't even venture to guess). This means that if your content isn't inherently slow (using poorly compressed images and tons of fragmented JavaScript and CSS files with broken ETags being consumed by HTML with script tags in "the wrong places", none of which is minified), CloudFlare is going to make your site slower. Really: the two things they ended up getting stuck in the ecosystem for were 1) being free or at a fixed low price for supposedly infinite bandwidth (though people report that when you actually use a ton, CloudFlare claims you are being attacked and need to upgrade to their protection racket, which leads us to), and 2) performing DoS attack protection by using a ton of annoying heuristics and IP filters and JavaScript delays and even captchas that you should notice no "real" site behind a normal CDN ever seems to need, and yet somehow is a hallmark of the experience of "this site is using CloudFlare".

acdha 10y ago
I've done a fair bit of testing and while their cache rate wasn't as high as Akamai, it wasn't as bad as you're making it sound: something like 50% vs. 60%. One of the challenges here is popularity: if you're a major site, yes, Akamai will have content cached at most of those 140k POPs but sites with different blends of cacheability and global traffic distribution might see a better cache hit ratio with fewer POPs so things stay hot in the cache longer. These are complicated services so the results are going to bay widely depending on what you need (e.g. having an optimized site means that every optimizer service I've tried made performance worse), and how much you can adjust your application to work with the CDN and tech changes like HTTP/2. The other reason why blanket statements aren't worth the time needed to make them is that these are not free services and you can get easily find cases where service A is better than service B but not enough so to justify the price. (Add for the DoS tools, note that that's pronounced “feature” by most people and at least personally I never see them except when testing through a commercial hosting company's network. Tor users whine a lot about them but that's just entitlement and unwillingness to think critically about what a site owner sees from their peers.)
- saurik 10y ago
  FWIW, I'm used to seeing >95% from working with CDNetworks (and I believe that's even in their literature somewhere), which has a kind of (to borrow a term from a different kind of service) "supernode"-like model for their cache layer, proactively distributes cached resources, and does revalidation as a separate path from fetches. As for their DoS "features", yes: they have a bunch of features because it makes them look like they are doing something worth value, but I am going to again remind you that somehow you never see websites that are using normal CDNs suddenly give up and give you an Akamai-branded captcha, and yet somehow they do not crumble under the weight of denial of service attacks; it just isn't the case that using CloudFlare is the only way to be safe from DDoS, and there's something weird about how the experience of using a CloudFlare website somehow is noticable.
- deleted 10y ago
  [deleted]