So basically this is Edge Side Includes reinvented?
Kinda, but without the pain of having to rewrite your pages, and with a much higher efficiency. Actually have a blog post about this queued up to go out tomorrow.
Caching the uncacheable: CloudFlare's Railgun
61–70 of 71 posts
Re: Caching the uncacheable: CloudFlare's Railgun
#62Earlier quoted context omitted.
Holy cupcakes. I might use this. So I can use your free package which includes the CDN to serve 100 Mbps of static JS and images?
Yes. And we'll also send you some cupcakes.
What do you have to say to http://news.ycombinator.com/item?id=4188882 ?
Re: Caching the uncacheable: CloudFlare's Railgun
#63Re: Caching the uncacheable: CloudFlare's Railgun
#64As a small company, using CloudFlare as a cloud-based CDN/firewall/DDoS protection looks very attractive. The thing that has stopped me from trying it is that you have to move your whole DNS to them though, and they have had downtime for DNS as well as their hosting. I'm comfortable with serving www.example.com through them and dealing with the occasional downtime. But I'm not so comfortable with downtime for MX reco…
I launched a startup in late March, using Cloudflare, and had many similar thoughts. But it was an awful experience. Because Cloudflare acts as a proxy, it gets in your way in subtle but devastating ways. First, the SSL support wasn't stable and I turned it off a few days into launch. That probably killed some traffic. Then, I realized that caching was an all-or-nothing proposition. You can have Cloudflare cache your…
> You can have Cloudflare cache your assets, but it doesn't seem to respect expires headers.
Why do you expire assets at all? If it's because you are deploying new versions of the app, would it not be better to solve this by using revision-stamped URLs? When you deploy a new version of your app, just change the stamp and let the old assets expire.
This has the secondary benefit of ensuring that all application-served pages use the assets the page was designed for, ie. avoiding the race condition when a user gets served a page from app version 1, but gets the asset for app version 2. (If app version 2 has changed an internal API used by the JavaScript, for example, this will result in actual app errors, not just a page that looks a bit weird due to mismatched CSS rules.)
Invalidation is a challenge with any kind of caching system. Invalidating passively by changing the cache key means that the cache has to keep more old cruft around until it expires naturally, but it's easier to implement and works around the race condition problem.
Re: Caching the uncacheable: CloudFlare's Railgun
#65Do any other CDN providers have similar technology as Railgun?
Good question. The answer should be obvious, as CloudFlare presents this for the innovative and ground breaking technology it is...
[end sarcasm]
So yeah, basically almost all of them have it. Most have had it for years. CDN and various other business models (POP's, etc.) have been converging for a while now, so this has become pretty standard for CDN's to provide.
Re: Caching the uncacheable: CloudFlare's Railgun
#66Pushing 0.5kb opposed to 93kb to a downstream caching proxy isn't going to set the world on fire if you consider the data transfer speeds we typically achieve these days, especially if you also consider the processing overhead on both your network and the cache provider. They're not really caching the uncacheable, either.
If you're on the wrong side of a really long high latency link, it should make a big difference. Slow start, etc. Leaving a persistent connection between the cache and the server obviously does most of it (especially with latency mitigation tricks/tcp acceleration). It would be interesting to calculate the benefits of nothing vs. a cache with an accelerated persistent tcp connection vs. deltas. I suspect it's somethi…
Slow start is irrelevant in the context of a CDN.
Cloudflare is like a bunch of people suddenly realized what every CDN in the world with a dynamic acceleration product does, but then they blog about as if it's all magic and unicorns.
Every DSA provider maintains persistent connections to origin nodes. Every DSA provider runs a custom multiplexing protocol between the first and last mile POPs on their network. Nothing here is new.
The only moderately interesting thing about this is that they're sending X bytes instead of Y bytes once every 60 seconds. Meh.
Re: Caching the uncacheable: CloudFlare's Railgun
#67If understand this correctly: 1. You install "Railgun" on your publishing web server 2. It pushes deltas of your webpage to CloudFlare 3. Who then update their cache of your webpage across their CDN. It seems as though folk are starting to see that in most environments caching ought to be driven by POSTs, not GETs + timeouts.
> It seems as though folk are starting to see that in most environments caching ought to be driven by POSTs, not GETs + timeouts. HTTP supports that too (through ETag and 204 Not Modified).
204 is no content. Think you meant 304.
Re: Caching the uncacheable: CloudFlare's Railgun
#68Do any other CDN providers have similar technology as Railgun?
Good question. The answer should be obvious, as CloudFlare presents this for the innovative and ground breaking technology it is... [end sarcasm] So yeah, basically almost all of them have it. Most have had it for years. CDN and various other business models (POP's, etc.) have been converging for a while now, so this has become pretty standard for CDN's to provide.
Really? Well may be they are for the big boys, none of the commonly used CDN advertise it, All Hosting providers reselling Level 3, Akamai, EdgeCast, NetDNA or even Amazon Cloudfront dont show it either.
I wonder why these aren't available to normal users.
Re: Caching the uncacheable: CloudFlare's Railgun
#69Earlier quoted context omitted.
Good question. The answer should be obvious, as CloudFlare presents this for the innovative and ground breaking technology it is... [end sarcasm] So yeah, basically almost all of them have it. Most have had it for years. CDN and various other business models (POP's, etc.) have been converging for a while now, so this has become pretty standard for CDN's to provide.
Really? Well may be they are for the big boys, none of the commonly used CDN advertise it, All Hosting providers reselling Level 3, Akamai, EdgeCast, NetDNA or even Amazon Cloudfront dont show it either. I wonder why these aren't available to normal users.
Not sure about Amazon and NetDNA, but the rest certainly offer it.
Re: Caching the uncacheable: CloudFlare's Railgun
#70Do any other CDN providers have similar technology as Railgun?
Good question. The answer should be obvious, as CloudFlare presents this for the innovative and ground breaking technology it is... [end sarcasm] So yeah, basically almost all of them have it. Most have had it for years. CDN and various other business models (POP's, etc.) have been converging for a while now, so this has become pretty standard for CDN's to provide.
Exactly right. This all just marketing spoof a way to justify recent re-distribution of paid plans.
For those who consider CF, know that they are a good company, but they should focus of product quality and not just of Marketing and PR.
For a better alternative I advise to check Incapsula.
Here is a head-2-head user review of both platforms.
http://www.husdal.com/2011/07/01/incapsula-versus-cloudflare...