Caching the uncacheable: CloudFlare's Railgun
blog.cloudflare.com
Caching the uncacheable: CloudFlare's Railgun
1–10 of 71 posts
Re: Caching the uncacheable: CloudFlare's Railgun
#2Re: Caching the uncacheable: CloudFlare's Railgun
#3Re: Caching the uncacheable: CloudFlare's Railgun
#4Re: Caching the uncacheable: CloudFlare's Railgun
#51. 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.
Re: Caching the uncacheable: CloudFlare's Railgun
#6A fully server-side solution will probably bypass most problem cases, but might solve some, so I hope CloudFlare looks into contributing to a distributed standard solution.
Re: Caching the uncacheable: CloudFlare's Railgun
#7Would love to see some real world figures on the difference in page loads. Intuitively it feels like a lot of overhead outside of the packets being saved between the host server and cloud flare.
With a different hosting partner (and a different set of sites) we saw a page download time speedup of between 2.94x and 8.12x.
Re: Caching the uncacheable: CloudFlare's Railgun
#8If 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.
HTTP supports that too (through ETag and 204 Not Modified).
Re: Caching the uncacheable: CloudFlare's Railgun
#9That being said, I'd have used another name ;à