Railgun Gives our Ecommerce Sites the Edge

The following is a guest blog post by Chris Holland, Director of Technology at Luxury Link. Luxury Link has been using CloudFlare’s Railgun acceleration technology since March 2013.

In March 2013, we started testing Railgun, and slowly rolled it out across our three web properties. We saw immediate results.

First, we saw instant reductions in time to retrieve uncached HTML documents, and as an ecommerce web property every millisecond counts. Using Railgun, the HTML for our home page (hosted in Los Angeles, California) loads 40 percent faster from the East Coast in the United States. Measurements we've run from London showed a 2x speedup, which is invaluable in positioning ourselves as a global player in the travel industry.

Second, we saw a reduction in outbound bandwidth from our origin web servers. Because Railgun does compression between the origin server and CloudFlare’s data centers, our bandwidth needs were dramatically reduced. This is especially important for our business because sudden peaks of traffic are commonplace.

We had tried other dynamic acceleration products offered by top-tier CDNs, but the results weren't as good and they cost a lot more than the CloudFlare Business plan.

Railgun, to put it mildly, was rather impressive.

We had the sneaking suspicion that Railgun's delta compression algorithm might have a noticeable impact on outbound bandwidth consumption out of our data center. In fact, it was more than noticeable!

In the chart below, the green line shows our outbound bandwidth consumption over a six month period. You can see that before we turned Railgun on in March, there are many spikes. Post-March, the spikes disappear.

It is important to note that with or without Railgun enabled, all of our HTML documents are delivered using gzip encoding. All our images, stylesheets and scripts are cached in CloudFlare data centers; as such they barely factor in the outbound bandwidth consumption. It's for the most part fair to state that our outbound bandwidth consumption is solely comprised of the retrieval of uncached HTML documents.

For us, this is why Railgun makes such a difference on top of the traditional CDN benefits. Railgun is accelerating and compressing the parts of the site that a normal CDN just can't handle. By accelerating the delivery of ‘uncacheable’ HTML pages, our visitors are getting better response times and we are seeing a big decrease in outbound bandwidth.

This chart shows the inbound (orange line) and outbound (green line) bandwidth on February 6, 2013, before we introduced Railgun. It shows a pretty typical story for us: dramatic peaks in traffic linked to specific email campaigns.

The data shows that our outbound bandwidth is between 5x and 10x our inbound. That's pretty typical of gzipped HTTP traffic serving mostly HTML: inbound traffic is made up of HTTP requests, most of which fit in a packet or two, while outbound traffic is made up of all the actual HTML documents in response to those requests.

Our peak traffic often comes from email campaigns sending users to some of our largest HTML documents, which is why we're more likely to come in at a 10:1 ratio. Off-peak outbound is still about 5x inbound traffic, and reflects a longer tail of smaller HTML documents from more organic browsing.

Next take a look at this chart from May 8, 2013, with CloudFlare Railgun running on our site:

Railgun shines when many users access a handful of similar URIs, which is the pattern of our peak traffic. Even though the documents being returned are different in subtle ways for each user, those unique subtleties are the only bits of information exiting our data center. Think "diffs." Railgun essentially flattens our peaks: going from a 10:1 ratio to a 1:1 ratio, our peak outbound traffic is 1/10th of what it used to be before Railgun.

Off-peak outbound traffic, which is the longer-tail organic browsing, is also down to a 3:1 ratio from a 5:1 ratio without Railgun.

After much hard work internationalizing our platforms, we were extremely thrilled to launch our site in the UK just before July 4th: http://www.luxurylink.co.uk. As we expand internationally, our audience will continue to grow geographically further from our data center located in Los Angeles, California, and Railgun will have an even greater impact by ensuring less data has to travel over increasing distances. Our UK site is also backed by Railgun.

While Railgun is likely to have a different impact for every application based on trafficked URIs and heterogeneity of documents, our observations would indicate that the impact for most web applications will fall somewhere between "noticeable" and "unbelievable."

Looking at these numbers, Railgun ought to be extremely attractive to cloud-hosted companies, such as people using services like Heroku, AWS or the Rackspace Cloud, as well as anyone paying for every single byte transferred in and out of their applications.

I would love to one day see Railgun's "edge agents" implemented as Chrome, Firefox, or Safari extensions. Right now, while very significant in terms of percentage, Railgun's acceleration is only marginally "felt" by end-users: full HTML documents are still sent to end-users from CloudFlare's edges. Picture a day when this "diff'ing" technology gets baked into the web browser, such that a web property becomes faster as you browse it because you're rarely ever retrieving a full HTML document for a given request, but rather a small HTML fragment which might fit in a single packet.

Dreaming up possibilities afforded by CloudFlare's platforms could be a full-time occupation. But before getting too far ahead of ourselves, Railgun as it stands today ought to be wildly transformative to the Internet and the many businesses that operate online. It certainly is to us.