Is Dreamhost's Railgun currently working?


#1

As the title suggests; for the last few days I’ve noticed all of my site requests have the response header of “Cf-Railgun: direct”, meaning the requests haven’t tried to use Railgun at all.

Now, I don’t know anything about the inner working of Railgun, it was working (after a fashion*) after I set it up, but it now just seems to be bypassing the Dreamhost Railgun daemon entirely. Possibly there’s more traffic than the Dreamhost daemon was expected to receive? I dunno, just curious what other people’s observation have been.

*I’ve already reported an issue to CloudFlare themselves, though I dunno how long it would likely take to fix, but personally I’ve been finding any improvement from Railgun to be, well practically non-existant. Even loading exactly the same URL in two different browsers both report a compression ration of around 100% (no reduction in size), they don’t see a change until you refresh the page.

That could be an issue with my headers maybe, but I was under the impression that Railgun wouldn’t care if pages are private or whatever, since it’s just extracting common elements in order to provide improved compression.

Anyway, please post any thoughts on how it’s been working for you! I’m interested to see if other people’s experiences have differed much.


#2

Sorry to bump, but really none of my sites are seeing anything from Railgun anymore and haven’t for over a week, the Cf-Railgun header always shows “direct”, is anyone else using Railgun? Are you getting a normal Cf-Railgun header? (should have various numbers etc. representing transaction, compression and such).


#3

We’ve just discovered that we were running a slightly outdated version of railgun (our version was 3.3.3, while the latest is 3.3.4). We’ve just updated all of our railgun servers, so hopefully you’ll see your sites begin to use it more instead of bypassing. We’re also working on more automated systems to make sure that we keep our railgun servers as up to date as possible. Other than keeping our version up to date, there isn’t all that much we can do; CloudFlare’s servers are what get to decide whether it will use it or bypass railgun. I suspect it’s possible that if you’re accessing your site from a geographic location close to our servers, it may automatically bypass railgun since it detected that the additional latency of going through the railgun server (it’s adding one more server that the connection must go through, as well as a little CPU time to compress/decompress the data) outweighed the performance gains from compression, but this is just my speculation. It’s also possible that CloudFlare is using some more complex criteria to bypass it for sites with little traffic, etc. Only CloudFlare would know for sure how it works and how it decides whether to use or bypass railgun.


#4

Thanks for the update!

Yeah it does seem like updating the Railgun version fixed it, as all pages are reporting railgun headers correctly again, CloudFlare must just automatically bypass a Railgun daemon that’s running an outdated version. I wouldn’t have thought a minor version increment would be enough to cause it, but it’s running like it did before, thanks!