6 ms·

How large is the per site cache? Are cookies part of the hash (and if so how do you strip meaningless cookies)? Otherwise the this is more compelling for conte

by glymor 14y ago

How large is the per site cache? Are cookies part of the hash (and if so how do you strip meaningless cookies)? Otherwise the this is more compelling for content sites like the referenced 4chan. But still very cool.

jgrahamc 14y ago
There isn't a per-site cache in Railgun because it's part of our large shared in-memory cache in our infrastructure. Currently, cookies are not part of the hash. We have customers of all types using Railgun. As an example, there's a British luggage manufacturer who launched a US e-commerce site last month. They are using it to help alleviate the cross-Atlantic latency. At the same time they see high compression levels as the site boilerplate does not change from person to person viewing the site. What sort of sites do you think it doesn't apply to?
- justinsb 14y ago
  Surely there is a per-site cache on the origin server (in what you call the "Listener")?
  - jgrahamc 14y ago
    Yes. That's up to the particular configuration of the site. It varies from site to site, but for optimal results you want it big enough to keep the content of the common pages of your site.
- glymor 14y ago
  > What sort of sites do you think it doesn't apply to? Single page webapps. In those cases the html/js is normally static and already CDN'ed and the data is a JSON API which varies on a per user basis. There would be some gain as the dictionary would learn the JSON keys but I doubt it would be very dramatic vs deflate compared to the content sites referenced in the article.
justinsb 14y ago
Presuming this is RFC 3229, this is transport compression, not webserver offload. The response is generated by the origin webserver as normal. But rather than sending that response using the normal HTTP encoding, instead the proxy first does a binary diff against any versions that the (CloudFlare) client says it has and that the (CloudFlare) proxy also has in its cache. They use e.g. ETags or MD5 to uniquely identify the entire response content. You can still do cookie stripping etc to try to avoid the request to the webserver altogether, but that's a separate concern.

by glymor 14y ago

jgrahamc 14y ago

There isn't a per-site cache in Railgun because it's part of our large shared in-memory cache in our infrastructure. Currently, cookies are not part of the hash. We have customers of all types using Railgun. As an example, there's a British luggage manufacturer who launched a US e-commerce site last month. They are using it to help alleviate the cross-Atlantic latency. At the same time they see high compression levels as the site boilerplate does not change from person to person viewing the site. What sort of sites do you think it doesn't apply to?

justinsb 14y ago
Surely there is a per-site cache on the origin server (in what you call the "Listener")?
- jgrahamc 14y ago
  Yes. That's up to the particular configuration of the site. It varies from site to site, but for optimal results you want it big enough to keep the content of the common pages of your site.
glymor 14y ago
> What sort of sites do you think it doesn't apply to? Single page webapps. In those cases the html/js is normally static and already CDN'ed and the data is a JSON API which varies on a per user basis. There would be some gain as the dictionary would learn the JSON keys but I doubt it would be very dramatic vs deflate compared to the content sites referenced in the article.

justinsb 14y ago

Presuming this is RFC 3229, this is transport compression, not webserver offload. The response is generated by the origin webserver as normal. But rather than sending that response using the normal HTTP encoding, instead the proxy first does a binary diff against any versions that the (CloudFlare) client says it has and that the (CloudFlare) proxy also has in its cache. They use e.g. ETags or MD5 to uniquely identify the entire response content. You can still do cookie stripping etc to try to avoid the request to the webserver altogether, but that's a separate concern.