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.
Bandwidth needs halved by new compression written in Go
51–60 of 121 posts
Re: Bandwidth needs halved by new compression written in Go
#52How 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.
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?
Re: Bandwidth needs halved by new compression written in Go
#53How 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.
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.
Re: Bandwidth needs halved by new compression written in Go
#54How 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.
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 level…
Surely there is a per-site cache on the origin server (in what you call the "Listener")?
Re: Bandwidth needs halved by new compression written in Go
#55Earlier quoted context omitted.
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 level…
Surely there is a per-site cache on the origin server (in what you call the "Listener")?
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.
Re: Bandwidth needs halved by new compression written in Go
#56Question for jgrahamc: how much more efficient is your binary delta algorithm than cperciva's bsdiff [1]?
I assume since you've got the preimages of compression, as well as control over the compression format, that the diff and patch operations are much more efficient in space and time than they would be with arbitrary binary data. But...by how much?
Re: Bandwidth needs halved by new compression written in Go
#57Question for jgrahamc: how much more efficient is your binary delta algorithm than cperciva's bsdiff [1]? I assume since you've got the preimages of compression, as well as control over the compression format, that the diff and patch operations are much more efficient in space and time than they would be with arbitrary binary data. But...by how much? [1] http://www.daemonology.net/bsdiff/
I am particularly interested in this aspect of the discussion (explaining the process leading to deciding to develop a new tech in-house instead of re-using any existing approach). In an ideal world there would be plenty of experimentation with real-world data to justify things, but I don't read about that happening too often.
Re: Bandwidth needs halved by new compression written in Go
#58The title suggests that there's something unique about Go, either the language or its standard library, that enables bandwidth savings. In fact, Cloudflare have written some software which they claim enables them to reduce their bandwidth, and this software happens to be written in Go. This might be an excellent choice (and I suspect it probably is), but it's not Go per se that is reducing the bandwidth usage.
I agree. The benefit of using Go is that it's fast to write and has good concurrency features. To give you an idea of the size, there are 7,329 lines of Go code in Railgun (including comments) and a 6,602 line test suite. In the process we've committed various things back to Go itself and at some point I'll write a blog on the whole experience, but one thing that made a big difference was to write a memory recycler s…
Go does look awesome. I've spent some time with Erlang, Clojure and Scala (roughly in the order that I liked them most), but Go passed the "get started writing useful code quickly" test better than any of them. Haven't gone beyond the basics yet, but I think it might occupy a sweet spot of ease of use combined with "power", loosely defined.
Re: Bandwidth needs halved by new compression written in Go
#59The title suggests that there's something unique about Go, either the language or its standard library, that enables bandwidth savings. In fact, Cloudflare have written some software which they claim enables them to reduce their bandwidth, and this software happens to be written in Go. This might be an excellent choice (and I suspect it probably is), but it's not Go per se that is reducing the bandwidth usage.
The title only suggests something unique about Go to those who didn't read the article.
There's a good chunk of that article dedicated to discussing the language choice and how other languages could have been used instead but -in this specific instance- wasn't chosen. The language choice is as much a part of the topic as the compression routines themselves. So it makes a lot of sense to include the term 'Go' in the title given that's a large focus of the article.
It's really no different to all these articles that spring up about fancy demos being built in Javascript or CSS tricks. Yet in those instances nobody says "the title is misleading. You could write that demo in C++ as well."
Re: Bandwidth needs halved by new compression written in Go
#60Earlier quoted context omitted.
Is anyone aware of a performance analysis between SDCH and one of the dynamic compressions like deflate? I google, but all I find is people complaining their proxy/filter/appliance/diagnostic is breaking because it doesn't understand SDCH. It seems like SDCH has been around for 4 years, I presume the lack of data means it hasn't worked out. (I imagine that you could drastically reduce the CPU load of compression by m…
What you describe is exactly what I've been looking for. There are remarkably few resources on this. We have users in Singapore who access various XML-heavy web services in our NY office. A dictionary-style over-multiple-requests compression technique would be brilliant for their case.
Take a look at the various WAN accelerator appliances (Cisco, Silverpeak, Riverbed). They do almost exactly what it sounds like you want (if I'm remembering back to my evaluations, Cisco at least uses a multi-request dictionary for their compression)