5 ms·

I'm so over Cloudflare. I've tried their service twice: The first time, I used a demo account at their Enterprise service level and compared it to our existi

I'm so over Cloudflare. I've tried their service twice: The first time, I used a demo account at their Enterprise service level and compared it to our existing CDN (Akamai). Our page load times increased across the board. When I asked them about implementing the L7 customizations that we have in our Akamai setup, I was told that it would take custom development and that we would have to pay for it--stuff that we were able to implement at Akamai using their XML configuration. Akamai is not an awesome company to work with and the XML configuration format is a nightmare but the service is fast and we didn't need custom dev work to get it running. The second time I tried Cloudflare was a few months ago for a personal project. I run a moderately popular vBulletin forum in my spare time and I wanted to see if CF could speed up my site. The results were similar--Cloudflare actually slowed things down. I was at the free tier and perhaps I would have seen improvement at the $200/mo plan with Railgun but I wasn't going to waste any more time to find out. The nail in the coffin was when I discovered that they provided CDN services to ISIS propaganda sites and openly oppose any efforts to shut down the sites. I'm all for freedom of expression on the internet and it's certainly their right to support the distribution of jihadi videos featuring the beheading innocent aid workers but I'm not going to support it with my money.

blfr 12y ago
What kind of customizations do you use?
buro9 12y ago
I'm a CloudFlare customer, and now I work for CloudFlare... I've been a customer for years and an employee for months. I too originally tried CloudFlare and left, tried again and left again, before eventually trying it about 18 months ago and staying. I too run highly dynamic sites, the same as you a few were vBulletin forums and I also had a Django web app that has a login form on every page. In both cases the pages are not able to be cached. The vBulletin page has personalisation or CSRF tokens (login form) depending on your login state, and the Django web app CSRF tokens again act to prevent caching there. It is obvious to me now, as it is to you, that any asset (page in this case) that isn't cacheable is only resulting in an additional hop and the additional delay that introduces. The reason I eventually remained a customer is Railgun. Railgun is the missing link that allows dynamic content to be mostly cached with only the diff between requests passing over the wire between origin and CloudFlare. Dynamic content still isn't cacheable from the perspective of the origin or the end user, but Railgun doesn't send 99% of the page over the wire, just the diff (this is a simplistic explanation but works well enough for this). Railgun is the only thing that I personally felt took my highly dynamic sites and made them feel dramatically faster than going direct to the origin. It also works really well for APIs. Additionally, for vBulletin I'd recommend setting up a page rule so that your attachment.php file is aggressively cached. Especially if your vBulletin is configured to store attachments in the database as this will spare your database server. Of course, if you're running WordPress, Drupal, or a CMS designed to produce cacheable sites then Railgun isn't needed. CloudFlare does act like a silver bullet in those cases and by default the caching is very good and the speed improvement the end user experiences is dramatic. But for dynamic sites, Railgun and Page Rules help to get the best out of the service. Hmm, it may be worth us producing Knowledge Base articles for "gold configurations" for common web applications, or better still to provide some way for us to let you just tell us how you're using something like vBulletin so that we can configure some things for you and recommend the other things (Railgun) that will make a difference. On ISIS sites, it's likely true that amongst the millions of sites there are some that are probably related to terrorism, or to carders, or whatever else is unwelcome. We have a trust and safety team and of course they work with law enforcement and courts in all jurisdictions in which we operate. Our service is to protect customers from DDoS and other attacks, so to some extent yes we are a shield for our customers as we do protect origin servers. However any valid legal request from a court or law enforcement agency is respected. That's the way to have something removed, not a subjective policy applied in a non-transparent way by a private company.
- corobo 12y ago
  Any idea why Railgun is only available on the $200+ plans? Wouldn't it save CF a bunch of origin server bandwidth if everyone was able to use it?
  - buro9 12y ago
    I don't know that info for sure, but I'll risk hazarding a guess that it's to do with the fact that providing Railgun has a cost for CF. The CF servers need to manage a separate chunk of memory for the customer cache and this is outside of the shared caches that can be used for assets. It also requires you to install something on your server (the vast majority of CF features don't require this), and that introduces additional support costs. Wherever there is a real cost to supply a service, you usually see those things in the more expensive plans. Where it's possible to offer something at negligible cost, you usually see those things in the cheaper plans. And yes, if something has virtually no cost to offer then it's a benefit to the security and performance of the web in general if we can push those things into the free plans and give them to everyone. There are exceptions to this of course, Universal SSL is an example of a feature that has a cost but the benefit to customers and the web in general is so significant that we give that on the free plans.
    - corobo 12y ago
      Very good points made there, especially on the support costs that I'd not considered. Free users are expensive :) Thanks for the response
manigandham 12y ago
How were you using CloudFlare? I keep hearing this a lot and just want to make sure the setup is accurate... Most CDNs are used to cache static files (javascript, images, etc) so they download faster but the webpage still loads from the origin server. CloudFlare is different and proxies everything through their servers (that's the only way they can provide the protection and caching benefits). If your origin is close to your location, then it WILL increase latency because a request now has to go through CloudFlare's network, to the origin, then back through CloudFlare and then back to you. It's an extra jump that will add some latency to all page requests that have to go to the origin. It does help for far away users though because CloudFlare's private network and proxy servers can contact your origin server faster than the end-user making it all the way on their own connection. In either case - near or far - the latency should be minimal and definitely not something that adds seconds to load time. If your pages don't change much, you can also just cache the HTML itself on the proxy servers which will definitely decrease load time to pretty much instantaneous. POST requests will still go back to the origin through CF's network but the GETs should be fast and the higher-end plans give pretty precise control over how long the caching lasts. (You can also do this with modern CDNs with more control but they don't provide the security benefits and the other apps that are part of CF). EDIT: By the way, Hacker News uses CloudFlare.

blfr 12y ago

What kind of customizations do you use?

buro9 12y ago

I'm a CloudFlare customer, and now I work for CloudFlare... I've been a customer for years and an employee for months. I too originally tried CloudFlare and left, tried again and left again, before eventually trying it about 18 months ago and staying. I too run highly dynamic sites, the same as you a few were vBulletin forums and I also had a Django web app that has a login form on every page. In both cases the pages are not able to be cached. The vBulletin page has personalisation or CSRF tokens (login form) depending on your login state, and the Django web app CSRF tokens again act to prevent caching there. It is obvious to me now, as it is to you, that any asset (page in this case) that isn't cacheable is only resulting in an additional hop and the additional delay that introduces. The reason I eventually remained a customer is Railgun. Railgun is the missing link that allows dynamic content to be mostly cached with only the diff between requests passing over the wire between origin and CloudFlare. Dynamic content still isn't cacheable from the perspective of the origin or the end user, but Railgun doesn't send 99% of the page over the wire, just the diff (this is a simplistic explanation but works well enough for this). Railgun is the only thing that I personally felt took my highly dynamic sites and made them feel dramatically faster than going direct to the origin. It also works really well for APIs. Additionally, for vBulletin I'd recommend setting up a page rule so that your attachment.php file is aggressively cached. Especially if your vBulletin is configured to store attachments in the database as this will spare your database server. Of course, if you're running WordPress, Drupal, or a CMS designed to produce cacheable sites then Railgun isn't needed. CloudFlare does act like a silver bullet in those cases and by default the caching is very good and the speed improvement the end user experiences is dramatic. But for dynamic sites, Railgun and Page Rules help to get the best out of the service. Hmm, it may be worth us producing Knowledge Base articles for "gold configurations" for common web applications, or better still to provide some way for us to let you just tell us how you're using something like vBulletin so that we can configure some things for you and recommend the other things (Railgun) that will make a difference. On ISIS sites, it's likely true that amongst the millions of sites there are some that are probably related to terrorism, or to carders, or whatever else is unwelcome. We have a trust and safety team and of course they work with law enforcement and courts in all jurisdictions in which we operate. Our service is to protect customers from DDoS and other attacks, so to some extent yes we are a shield for our customers as we do protect origin servers. However any valid legal request from a court or law enforcement agency is respected. That's the way to have something removed, not a subjective policy applied in a non-transparent way by a private company.

corobo 12y ago
Any idea why Railgun is only available on the $200+ plans? Wouldn't it save CF a bunch of origin server bandwidth if everyone was able to use it?
- buro9 12y ago
  I don't know that info for sure, but I'll risk hazarding a guess that it's to do with the fact that providing Railgun has a cost for CF. The CF servers need to manage a separate chunk of memory for the customer cache and this is outside of the shared caches that can be used for assets. It also requires you to install something on your server (the vast majority of CF features don't require this), and that introduces additional support costs. Wherever there is a real cost to supply a service, you usually see those things in the more expensive plans. Where it's possible to offer something at negligible cost, you usually see those things in the cheaper plans. And yes, if something has virtually no cost to offer then it's a benefit to the security and performance of the web in general if we can push those things into the free plans and give them to everyone. There are exceptions to this of course, Universal SSL is an example of a feature that has a cost but the benefit to customers and the web in general is so significant that we give that on the free plans.
  - corobo 12y ago
    Very good points made there, especially on the support costs that I'd not considered. Free users are expensive :) Thanks for the response

manigandham 12y ago

How were you using CloudFlare? I keep hearing this a lot and just want to make sure the setup is accurate... Most CDNs are used to cache static files (javascript, images, etc) so they download faster but the webpage still loads from the origin server. CloudFlare is different and proxies everything through their servers (that's the only way they can provide the protection and caching benefits). If your origin is close to your location, then it WILL increase latency because a request now has to go through CloudFlare's network, to the origin, then back through CloudFlare and then back to you. It's an extra jump that will add some latency to all page requests that have to go to the origin. It does help for far away users though because CloudFlare's private network and proxy servers can contact your origin server faster than the end-user making it all the way on their own connection. In either case - near or far - the latency should be minimal and definitely not something that adds seconds to load time. If your pages don't change much, you can also just cache the HTML itself on the proxy servers which will definitely decrease load time to pretty much instantaneous. POST requests will still go back to the origin through CF's network but the GETs should be fast and the higher-end plans give pretty precise control over how long the caching lasts. (You can also do this with modern CDNs with more control but they don't provide the security benefits and the other apps that are part of CF). EDIT: By the way, Hacker News uses CloudFlare.