Re:Caching the uncacheable: CloudFlare's Railgun
by jgrahamc on Monday July 02, 2012 @08:30AM
(#4188543)
"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.
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 because the connection between the two parts of Railgun is kept active problems with TCP connection time and slow start are eliminated.
Just reread this part, and not sure I understand it. Yes, there are no extra packets between the proxies, but in the base case there is only a single proxy and hence no extra connection time to consider. I'd think even a very fast proxy would introduce more latency than a hop on a backbone router. Or are you indeed pushing the per-user delta to the data center in anticipation of the request?