I wonder if there's a way to replicate/simulate this with a longer ttl on the pages served out of your cdn, and a bit of javascript that pings a lighter weight server only asking for deltas, and updates the page in place (or reloads the entire page from the cdn when the deltas get too big).
Caching the uncacheable: CloudFlare's Railgun
41–50 of 71 posts
Re: Caching the uncacheable: CloudFlare's Railgun
#42I wonder if there's a way to replicate/simulate this with a longer ttl on the pages served out of your cdn, and a bit of javascript that pings a lighter weight server only asking for deltas, and updates the page in place (or reloads the entire page from the cdn when the deltas get too big).
Re: Caching the uncacheable: CloudFlare's Railgun
#43Exec summary: This is not caching. It is reduced latency for your visitors by removing connection setup over a large geographical distance. It also reduces the latency your web server has to deal with to effectively zero, but you can do that with Nginx. It also will reduce your bandwidth consumption from your providers perspective to a fraction of what it was. I think describing this as caching hides the real benefit…
CloudFlare does not bill customers for bandwidth consumed. It's a flat fee: https://www.cloudflare.com/plans
Re: Caching the uncacheable: CloudFlare's Railgun
#44Earlier quoted context omitted.
The numbers I'm reporting here are for the speed of download across Railgun and across HTTP between the origin server and a CloudFlare data center. Not the final download time to the end user. The issue with the end user number is deciding on what to report. We are currently rolling out a very large system for monitoring timing throughout our network and will be able (later this year) to report on actual end user tim…
Not the final download time to the end user. OK. Still a useful measure, but a less dramatic one. The issue with the end user number is deciding on what to report. I would think that time to show a slightly changed page after a "refresh" or "reload" would be appropriate. What are the other choices? For pages that are frequently accessed the deltas are often so small that they fit inside a single TCP packet, and becau…
"I would think that time to show a slightly changed page after a "refresh" or "reload" would be appropriate. What are the other choices?"
Well, what we really want to measure is the overall effect so that we can see how Railgun improves things in general. The 'refresh' time is interesting, but we're also interested in the network scale (how does user X downloading Y improve the speed for user Z downloading the same (but slightly different) page Y).
"but in the base case there is only a single proxy and hence no extra connection time to consider"
That isn't really the base case. The base case is that we need to go get the resource with a normal HTTP connection direct to the server.
Re: Caching the uncacheable: CloudFlare's Railgun
#45Exec summary: This is not caching. It is reduced latency for your visitors by removing connection setup over a large geographical distance. It also reduces the latency your web server has to deal with to effectively zero, but you can do that with Nginx. It also will reduce your bandwidth consumption from your providers perspective to a fraction of what it was. I think describing this as caching hides the real benefit…
CloudFlare does not bill customers for bandwidth consumed. It's a flat fee: https://www.cloudflare.com/plans
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?
Re: Caching the uncacheable: CloudFlare's Railgun
#46Earlier quoted context omitted.
CloudFlare does not bill customers for bandwidth consumed. It's a flat fee: https://www.cloudflare.com/plans
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.
Re: Caching the uncacheable: CloudFlare's Railgun
#47Tl
Re: Caching the uncacheable: CloudFlare's Railgun
#48Earlier 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.
I'm curious if I'm going to run into a catch. It seems unsustainable. Just to be clear, that's 30.8 Terrabytes of data I'll be transferring per month on your network for $0. Can someone verify this?
Re: Caching the uncacheable: CloudFlare's Railgun
#49Earlier quoted context omitted.
Yes. And we'll also send you some cupcakes.
I'm curious if I'm going to run into a catch. It seems unsustainable. Just to be clear, that's 30.8 Terrabytes of data I'll be transferring per month on your network for $0. Can someone verify this?
I'm not on the business side, but looking at our global traffic 30TB per month is a tiny percentage of what we are doing in terms of traffic.
I doubt it would go unnoticed, though, so I expect someone will be interested in persuading you to get a Business account with us which is $200/month because at that point we give you an SLA.
Re: Caching the uncacheable: CloudFlare's Railgun
#50Earlier quoted context omitted.
Yes. And we'll also send you some cupcakes.
I'm curious if I'm going to run into a catch. It seems unsustainable. Just to be clear, that's 30.8 Terrabytes of data I'll be transferring per month on your network for $0. Can someone verify this?
If they go down, you go down. But in my experience they have been quite reliable; if you aren't already in 3 sites on independent networks for HA, they are better.
I'd spring for the $200/mo service if you are pushing real traffic just to get to try the railgun. $200 is less than epsilon for a large site.
Also, the cupcakes are probably a lie, or at least are vegan.