Jump to content

Railgun from CloudFare


Recommended Posts

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Archived

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

  • Recently Browsing   0 members

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