Jump to content

Railgun from CloudFare


Recommended Posts

Posted

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.

cloudflare-direct.png

cloudflare-railgun.png

  • 4 months later...
  • 1 year later...
Posted
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?

Posted
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.

Posted
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. ?

Posted
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.

Posted
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?

  • 1 month later...
Posted
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?

Posted
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.

Posted
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.

Posted

@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)

Posted
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.

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...