Has anyone tried Railgun from CloudFare? It promises incredible TTFB and average 200% better speed:

https://www.cloudflare.com/railgun

I am using it for the past 15 days. Setting it up is a little tricky, but I have no regrets. Our forum got a little bit faster. The 200% better speed is in the communication between our server and their servers, not between CloudFlare and the end users. But, of course, this improves speed for the end user as well.

You can see it in action on my forum and website. For that, install the "Claire" extension for Chrome. This extension allows you to know if a website is using CloudFlare and which CloudFlare features are enabled, namely Railgun.

When you enter a Railgun-enabled website, the "R" on the extension lights up in red. Clicking on it will give you some basic statistics. If the page is not cached yet on the CloudFlare server you are using (which depends on your geographical location), it will show "direct". Reload the page with F5 and you should see the compression in action, and sometimes it shows the speed and compression percentage (I still don't know why sometimes these stats don't show up). Page load is at 0.2 seconds and compression is at 97%. See some screenshots below.

My website is www.clubedohardware.com.br and my forum is forum.clubedohardware.com.br

BTW. I decided to go with the Business account more for the advanced DDoS prevention.

@Gabriel Torres

This page (http://forum.clubedohardware.com.br/) is currently offline. However, because the site uses CloudFlare's Always Online™ technology you can continue to surf a snapshot of the site. We will keep checking in the background and, as soon as the site comes back, you will automatically be served the live version. Always Online™ is powered by CloudFlare | Hide this Alert

That is caused by the load issue (> 100) we are discussing in the other topic... Thanks... (this was happening before Railgun, and it is not related to it)

I am sorry, but for that price you can get way better things. For example a better uplink for your server.

On 19/02/2015 at 11:07 PM, Gabriel Torres said:

That is caused by the load issue (> 100) we are discussing in the other topic... Thanks... (this was happening before Railgun, and it is not related to it)

Are using the new feature for business plan Bypass Cache on Cookie?

On 2/18/2017 at 3:32 PM, sobrenome said:

Are using the new feature for business plan Bypass Cache on Cookie?

I was not even aware of this feature (we do have a business plan). What is it about?

3 hours ago, Gabriel Torres said:

I was not even aware of this feature (we do have a business plan). What is it about?

You are missing the very best feature:

https://blog.cloudflare.com/caching-anonymous-page-views/

4 hours ago, sobrenome said:

You are missing the very best feature:

https://blog.cloudflare.com/caching-anonymous-page-views/

IPS 4 already does that out of the box. I don' even know if its good policy to have both enabled.

1 hour ago, RevengeFNF said:

IPS 4 already does that out of the box. I don' even know if its good policy to have both enabled.

It caches the page on each POP of the CDN network. It's a huge difference.

And IPS does not cache the whole page, there is some php parsing and database query. On cloudflare, it's pure "html" cached. 

It's like a Varnish Cache over a worldwide CDN network.

@sobrenome many thanks! I didn't understand how to enable it...

1 minute ago, Gabriel Torres said:

@sobrenome many thanks! I didn't understand how to enable it...

I was trying to install Railgun right now but I have realized that I did not have mod_cloudflare on Easy Apache 4. I have tried to install it and it killed my Apache.

So for now I cannot help. ?

I disabled Railgun a while ago... It increased the load on our server too much.

3 hours ago, Gabriel Torres said:

I disabled Railgun a while ago... It increased the load on our server too much.

Bad news... I was so excited to add it to the server...

Have you contacted cloudflare to check it?

The conceptual idea of railgun is awesome.

On 21/02/2017 at 10:47 PM, Gabriel Torres said:

I disabled Railgun a while ago... It increased the load on our server too much.

Have you tried Bypass Cache on Cookie?

2 hours ago, sobrenome said:

Have you tried Bypass Cache on Cookie?

No...

On 2/21/2017 at 8:20 AM, sobrenome said:

You are missing the very best feature:

https://blog.cloudflare.com/caching-anonymous-page-views/

I've been looking at this and wondering, if you're caching entire page output for guests with this feature.. Doesn't that kill the topic view counters?  If it's caching everything for guests... The page view never hits your server to increase the topic view counters.

Is that correct or am I missing something here?

I guess that it could be correct, but not sure. Maybe a ticket on cloudflare to check if there is possible to solve this issue.

On 29.3.2017 at 8:33 AM, h2ojunkie said:

I've been looking at this and wondering, if you're caching entire page output for guests with this feature.. Doesn't that kill the topic view counters?  If it's caching everything for guests... The page view never hits your server to increase the topic view counters.

Is that correct or am I missing something here?

Yes, it would. 

However, it's not easy to utilize this in IPS 4 for another reason. The csrf-key is expected to be unique for each visitor on IPS, but if you decide to implement rules that would cache the pages for guests, then that would mean the csrf-key would also be cached. Thus, when trying to log in, you would get a csrf-key mismatch error if you've been delivered a cached version of the page which was generated by PHP/IPS-code for another guest.

This could create such issues for guests when they try to change the theme, language, or use the inline login form on any page. 

I personally wish IPS would reconsider how csrf-keys work/where it's used for guests and/or implement it to be switched out/retrived by an ajax-call to a specific url when necessary.

What if the login/register url is excluded from the caching rule?

8 hours ago, sobrenome said:

What if the login/register url is excluded from the caching rule?

Yes, you would have to do that, but the inline login form (the modal) on every other page, would still have the wrong csrf-key, so on the first attempt you would get the error. (Unless you right click to open the login page in a new tab for example)

You would have to make sure the login button didn't open a inline login form/modal/overlay and instead went directly to the /login/-page, where you would then fill out the form.

Thanks a lot for the tip. I have not tested the full cache feature yet on the whole site. I have set just an url for testing and it is very fast:

https://fisiculturismo.com.br/forum/topic/112508-dicas-primeiro-ciclo-de-stano/

It was not set to use bypass cache on cookie though because my account is not enterprise.

@Gabriel Torres I am from Germany and your page loads very slowly for me (4-8s according to chrome's dev tools). I assume CloudFlare / Railgun is not the reason for this, but if it loads a lot faster for you would that also mean that RailGun doesn't provide the advantages it promises?

PS: The IPS forum is incredibly quick for me (0.7s loading time)

@inkredible This delay is caused by the RTB ads we have running. With the ads disabled the page loads almost instantly, however, we need the ads to pay our bills...

On 3/30/2017 at 3:43 AM, TSP said:

Yes, it would. 

However, it's not easy to utilize this in IPS 4 for another reason. The csrf-key is expected to be unique for each visitor on IPS, but if you decide to implement rules that would cache the pages for guests, then that would mean the csrf-key would also be cached. Thus, when trying to log in, you would get a csrf-key mismatch error if you've been delivered a cached version of the page which was generated by PHP/IPS-code for another guest.

This could create such issues for guests when they try to change the theme, language, or use the inline login form on any page. 

I personally wish IPS would reconsider how csrf-keys work/where it's used for guests and/or implement it to be switched out/retrived by an ajax-call to a specific url when necessary.

Thank you for this detailed response.  That's something I hadn't even considered yet and you surely saved me countless hours going down the rabbit hole testing rail gun.  Back to the drawing board for me.  Maybe it's time to surrender and make the switch to an all AWS solution.  Oh how I dread the docs I'll be reading the next month.