

CloudFlare's new web protocol speeds up dynamic web performance - jgrahamc
http://blog.cloudflare.com/railgun-in-the-real-world

======
thomseddon
I must say, we recently upgraded to "Business" for the 100% uptime and the
layer 7 DDOS protection and were impressed with the prospect of using Railgun.

After a couple of days of trial and error (kept failing due to too many open
file handles) we now have it running smoothly but have noticed little to no
speed improvement both vs what it was before and vs other sites on the same
environment.

Would be interesting to know if anyone else has had a similar/dissimilar
experience...?

~~~
jaequery
i actually saw decreased performance. it seems if your server is already fast
(ivy bridge w/ ssd, 10gbps network), it slows it down and their service
becomes the bottleneck.

~~~
moe
Unless your servers are _really_ slow their service will always be the
bottleneck. I'll keep repeating this every time the Cloudflare spam comes up
on HN (which happens with disturbing frequency): Do your homework, _measure
them_. Cloudflare slows your site down instead of speeding it up. There is no
free lunch.

~~~
modoc
We don't have slow servers. We've measured before and afters on multiple
clients and have seen quick page render times on the client end after rolling
CloudFlare in. Caching static assets on a CDN (like CloudFlare) speeds up
overall page load time. The minification features around HTML, CSS, JS, also
improve transfer times. If you have optimized html, don't expect html serving
to be faster (as you have more hops - unless you use railgun maybe).

Homework done, measurements taken. Happy with the results.

~~~
druiid
Pretty much the same here... and we have the fabled e-commerce style pages
(because we do e-commerce).

The only thing that we saw a slowdown for was when we connect to pages from
our office, when our servers are in town.. but that's not the fault of
Cloudflare, but simply that they don't have servers in the same city as us!

------
rfugger
The headline made me pay attention to how long the article page took to load,
and it actually seemed quite slow to me.

~~~
bgentry
A quick dig reveals that to be the fault of Posterous, not CloudFlare:

    
    
        $ dig blog.cloudflare.com
        ...
        ;; ANSWER SECTION:
        blog.cloudflare.com.	21	IN	CNAME	blog.cloudflare.com.cdn.cloudflare.net.
        blog.cloudflare.com.cdn.cloudflare.net.	21 IN CNAME cloudflare.posterous.com.
        cloudflare.posterous.com. 1243	IN	A	184.106.20.99
    

So it looks like requests are going directly to Posterous. Seems like an
obvious place for CloudFlare to showcase their speed.

------
dsl
"Railgun" is just a fancy name for Cloudflare's implementation of DSA
(Internap and Akamai sometimes call it "Whole Site Delivery").

Every other major CDN offers some variation on this same service. Suck the
bits in at a server close to the origin, compress them using proprietary
voodoo, expand things at the server closest to the client.

Akamai owns the relevant patents on this (which it acquired from the Netli
acquisition) and has used them to sue then acquire other companies like
Cotendo. See <http://www.google.com/patents/US6820133> and
<http://www.google.com/patents/US7293093>

~~~
RobAley
I'm sure Cloudflare will comment, but it seems a little different to that.
Rather than suck the original bits in at a server close to the origin, it
looks like it takes the compressed (delta) bits direct from the origin itself.

~~~
modoc
Correct. It's ISN'T DSA. It's very promising for eCommerce sites which may
have a personalized header (Name, Cart Contents, etc...) and some customized
Ads/CTAs/Marketing slots, but where the bulk of the page (often a very large
page - 100+ KB) will be the same for everyone.

The obvious win is pushing less bytes across the wire. The less obvious win is
that it allows the application server response to complete VERY fast, freeing
up the app server thread to handle more requests. This is the larger win for
large scale 3-tier applications.

