Business Plan, Railgun and Cache Everything

Will persistent connection help in speed overall due to Railgin w.r.t to Backend and Edge POP connection.

i.e. Will Railgun help even with Cache Everything?

I understand that 2nd view will be from the Cache of POP but will first view for the POP will get the benefit due to Railgun.

Railgun will help with that first connection before the cache is populated. I think that’s a bit overkill, but if you’ve got Railgun, then use it.

1 Like

Never had Railgun but we are planning for Business Plan and but wanted the opinion of MVPs like you.

Is the Railgun connection always persistent ?

I don’t use Railgun, but I’m sure there’s an @MVP who’s tested it out.

1 Like

I’m actually not certain if the connection is persistent. I think it is at least long lasting between Cloudflare and the listener component. It still uses the same https/http from there to communicate with your local web server.

If your content is relatively cachable then, in my limited experience, the difference was minimal. I’ll also note my web server already compresses content, which railgun would otherwise help with.

But railgun helps significantly with less cachable content. Pages that have some dynamic data but are largely the same seemed to see the biggest boost.

2 Likes

Thank you dave for your experience.
Now we just need to know about whether the connection is persistent and that it’s beneficial.

Are you using Centos?

It’s persistentish, anyway. I’m running centos and Ubuntu. I think I tested on Ubuntu, but I’d actually have to double check as I’m slowly moving to centos.

1 Like

Railgun is for accelerating uncacheable content i.e. dynamically generated HTML and serving up just the compressed diff changes in binary format via a permanent TCP connection (like rsync would only transfer the parts that changed) on subsequent repeated page loads via a Railgun listener (installed on origin server) and sender (installed within each CF datacenter).

The sender and listener establish a permanent TCP connection that’s secured by TLS. This TCP connection is used for the Railgun protocol. It’s an all binary multiplexing protocol that allows multiple HTTP requests to be run simultaneously and asynchronously across the link.

To a web client the Railgun system looks like a proxy server, but instead of being a server it’s a wide-area link with special properties. One of those properties is that it performs compression on non-cacheable content by synchronizing page versions.

Each end of the Railgun link keeps track of the last version of a web page that’s been requested. When a new request comes in for a page that Railgun has already seen, only the changes are sent across the link. The listener component make an HTTP request to the real, origin web server for the uncacheable page, makes a comparison with the stored version and sends across the differences.

The sender then reconstructs the page from its cache and the difference sent by the other side.

so essentially it’s

visitor > cloudflare > railgun + memcached > origin server

on origin server you install railgun and memcached server which is a proxy in between cloudflare edge and origin server

see https://www.cloudflare.com/docs/railgun/intro.html

One of the major advantages of using Cloudflare is that cacheable content (such as images, JavaScript, CSS and HTML) is both cached by Cloudflare and delivered from our data centers around the world. Because Cloudflare has data centers covering the entire globe, cached content gets delivered quickly to web surfers wherever they are (and overcomes latency problems).

But only about 66% of content is cacheable. The other 34% must be obtained from the real origin web server. Railgun overcomes this problem by using a scheme that is able to cache dynamically generated or personalized web pages dramatically reducing bandwidth used and improving download times.

Railgun is a single daemon that runs on a 64-bit system which uses alternative compression techniques to dramatically speed up WAN performance.

It proxies traffic through a special protocol that would normally travel between Cloudflare and your origin server over HTTP.

Typically, the markup of websites, or the body a JSON API response, does not change that frequently from one request to the next. Instead of transferring the entire request between Cloudflare and your environment, Railgun will transfer only the changes in markup from one request to the next. This cuts down on bandwidth, transfer time, and overall page load times. Railgun caches these differences in memory to make page processing as fast as possible.

I use CF Railgun for my forum’s logged in member visits which are not cacheable. Then I use CF CDN cache + CF Worker proxy caching for guest non-logged in visitors. This way you have an optimal setup for both guests and logged in members.

2 Likes

@eva2000 Thank you for your delightful answer in-depth.

I am aware you are one of the most performance-hungry people w.r.t servers.
Can you give this answer?

Two pages A and B and Pop1

  1. A is requested via Pop1
  2. A is cached via Pop 1 even HTML
  3. B is requested via Pop1

Will B get the benefit (of point 3) of persistent connection between origin and Pop1 due to A getting fetched in Step 1.

Will B get this benefit even after say 12 hrs if A getting fetched.?

You do mention a Permanent TCP connection so I wonder will this help in future non cached pages as well?

it should as per

Each end of the Railgun link keeps track of the last version of a web page that’s been requested. When a new request comes in for a page that Railgun has already seen, only the changes are sent across the link. The listener component make an HTTP request to the real, origin web server for the uncacheable page, makes a comparison with the stored version and sends across the differences.

You can check Railgun stats via Railgun header too https://support.cloudflare.com/hc/en-us/articles/200168426-How-can-I-tell-if-Railgun-is-running-on-my-site-

When you are looking for the header information, you should be seeing Cloudflare headers like the following in the response:

cf-railgun : e95b1c46e0 0.02 0.037872 0030 9878

cf-ray: 478149ad1570291

The CF-Railgun header has up to five codes separated by a space. In order, these codes and their corresponding values from the example of cf-railgun : e95b1c46e0 0.02 0.037872 0030 9878 listed above are:

  • Railgun Request ID: e95b1c46e0 (internal process number that allows us to track what connection handled a request )
  • Compression Ratio: 0.02 (the size of the response after Railgun’s delta compression expressed as a percentage)
  • Origin Processing Time: 0.037872 (that Railgun waits for the origin web server to generate the page)
  • Railgun Flags: 0030 (how a request was processed)
  • Version Number: 9878 (indicates the version of the Railgun Listener software on the origin server’s network)

Don’t think so it’s done at a HTML page level AFAIK

1 Like

Okie since the URL of A and B are different and say there is considerable time between their requests then Railgun will not be able to help via its Persistance connection.

Thank you @eva200, the day I am able to hire you for whole cloud setup/Architecture is the day I am somebody.

Thank you for your complete answer.

2 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.