Review: Flarum on AWS + CloudFlare (updated Oct 23, 2015)

viet

Hello guys,

First of all, I want to thank the Flarum team for making this software possible. I've been using many forum softwares for over 10 years (since I was a little kid, back in 2000), both as an user and an admin. Using Flarum is quite a joyful experience.

It all started when I first heard about Flarum from various communities a few months ago. During that time, I have been using Xenforo for my main website. Recently, I was looking for a new forum software to test around, and see if it inspires any idea for a new forum (I'm still using Xenforo for my current forum). I looked at phpBB, Vanilla, Discourse, NodeBB, and Flarum. Here are the criterias I used to find what fit my need:

Easy to implement on AWS: My other websites are hosted on Google App Engine, and Google Cloud. However, being an AWS certified solutions architect, I thought I should build some high scalability website on AWS also.
MySQL type database: Being on AWS, the software should be compatible with the easiest managed database solutions on AWS so I don't have to maintain database. Discourse uses PostgreSQL (AWS supports it), NodeBB uses Redis (supported). All the other softwares use MySQL/MariaDB (supported). I don't have to remove anything from the list.
Modern UI: This really comes down to preferences, so I will try to use my target audiences. I'm planning to make a forum for young Vietnamese people and expats in Vietnam to share culture. The target audiences are young, not tech savvy people, but they like beautiful UI with simplicity. I found that NodeBB, Discourse and Flarum are all one page applications with beautiful UI out of the box. I remove phpBB & Vanilla from the list and go with those more modern forums.
Open sourced: I have to remove Discourse because I'm not looking for adding licensing fee to my budget. (Edit: Discourse is indeed open sourced, for some strange reason I just like to compare NodeBB and Flarum better)

It now comes down to NodeBB and Flarum. They're both great, and it's a hard decision. I took a leap of faith and went with Flarum because of the following reasons:

AWS supports MySQL, MariaDB and Aurora, it means that I can achieve better scalability if my forum goes popular. I'm not saying that Redis is not scalable, but
PHP language is easy to work with and to hire developers for.
I have never seen any PHP forum software that is as beautiful (one page application and simple looking) as Flarum. I think it will be great and easy enough for my users to use.
I found Flarum to be fast and have great performance score on GTmetrix, so the development team must have done something right. We're still in early stage and I feel that you guys take care of the product well and didn't add any bloated unnecessary features.

My next step was to test how well it works with AWS. Here's the current setup for https://viet.vn

EC2 instances in 3 availability zones, behind 1 Elastic Load Balancer.
Autoscaling is enabled
The AWS load balancer is behind CloudFlare proxy with CloudFlare Railgun enabled to reduce bandwidth cost and optimize speed.
Amazon RDS MariaDB for database.
Amazon ElastiCache with Memcached enabled for CloudFlare Railgun support
Most importantly, Elastic File System to unify one central folder for all web contents, including avatars and attachments that will be generated by users. This is one of the reasons why I use AWS.

The result: It loads pretty fast and achieve high pagespeed score within the US (The infrastructures are located in Oregon, US-west 2). However, from Southeast Asia, it takes about 3 seconds to load a few first page. I think lots of caching and optimization so that low end computers/phones can access will be necessary, it'd be wonder.

What I love about Flarum:

Relative path: Just like many other large websites that terminate SSL on the load balancer level, I found that Flarum use relative path really well. Let me describe it a little bit: All EC2 instances run on port 80, config.php set https://viet.vn as the web address, load balancer (in my case CloudFlare's Flexible SSL) takes traffic on port 443, decrypt and terminates at CloudFlare level, pass all traffic back to AWS ELB and EC2 via port 80. It results in no performance hit on the web server, and still make the website secure. Why does it make my site secure when I terminate SSL at CloudFlare level? Because CloudFlare and Amazon Web Services use the same data centers in most regions (Oregon, Virginia, etc..)
Fast loading: It's one of the fastest and most lightweight forum softwares I've ever seen.
PHP & MySQL: This means that if the site goes popular, and if I want to make modification to the site, I can easily find PHP developers to do it.

How Flarum could work better:

Better PaaS like compability: Use external services whenever necessary. For example, most PaaS don't have a shared consistent file system, so it's better to generate new static contents (avatars, attachments) to external services like imgur, S3, Google Cloud Storage, etc..
CloudFlare compability: Try CloudFlare, it increases Flarum forum load speed, and add SSL for free. Since Flarum relies on Javascript and aim to be very fast, it's best to test compability with CloudFlare's Rocket Loader feature. It allows javascript to be loaded asynchronously. However current version of Flarum doesn't work well with Rocket Loader (blank content page on load at times).
Caching: Either Memcached or Redis, or both. Redis can be used to store session/state, etc.. while Memcached can be used to cached frequently accessed pages/keys.

(to be continued, I'll write about how well it works with AWS and CloudFlare soon)

Franz

viet Better PaaS like compability: Use external services whenever necessary. For example, most PaaS don't have a shared consistent file system, so it's better to generate new static contents (avatars, attachments) to external services like imgur, S3, Google Cloud Storage, etc..

The way e.g. the uploading code currently works will make it very easy to simply swap in adapters for other storage layers like S3 etc. We just have to make that configurable, and will do so. 🙂

Netsoft

@viet

As far as I know Discourse is an open source software and will remain free for now.
Probably the fees that you saw are the "installation charges".

viet

Netsoft Oh not sure why I thought of it that way. I'll review discourse again but will most likely stay with Flarum. For some reason I feel that Flarum can go a long way.

Netsoft

viet Yep, I like Flarum too. Can't wait for the final release.

tankerkiller125

I think (personally and through experience) that redis is a better Cache option than many if not all of the other solutions. Although I would never recommend it for storing extremely important data (full threads and what not) but as a cache option it works extremely well. Also after my own testing (auto-scaling groups and all) I find extremely similar results which just proves how consistent Flarum is compared to many/all of the other solutions.

viet

tankerkiller125 True that, redis is very fast, we use it for our Minecraft cluster to sync real time player data. Maybe Redis can be used for Flarums sessions/states.

Maybe Flarum can take advantage of both Memcached and Redis (both are supported by AWS's ElastiCache service), using both into their advantage. @Franz would know best what to do with Flarum performance. I can always help test to compare performances and load time.

I simply hope that the least data/packets are sent possible for each Flarum web request, so that users from far away can browse the forum feeling that everything loads instantly.

I'm currently in Vietnam, testing Flarum on both Oregon and Japan locations with the latency from Vietnam respectively 200ms and 100ms. I found that loading websites from Japan feels instant whereas loading the content box takes 1 to 2 seconds to load some times. It caused me to believe that more caching and opmitizing of packets being sent through the internet would be a nice solution.

Dominion

Great writeup @viet ! Just out of curiosity, who do you host with in Japan?

I look forward to reading the rest of your results.

viet

Dominion I use AWS for both Oregon and Japan location. However, Japan location doesn't have EFS (Elastic File System) to unify a /var/www folder across many instances.

I'm asking AWS to release EFS in Japan location, hopefully they'll consider. As of right now https://viet.vn is back in Oregon region.

Dominion

I see, thanks! I was wondering if you weren't back in Oregon now, it was feeling kinda sluggish to me. 😉

viet

Dominion As of right now it still feels sluggish to you?

For the sake of transparency and improving performance, lemme share a few technical details:

All of the EC2 instances are t2.micro (burstable CPU, 1GB RAM) which is the minimum configuration for AWS EC2.
I installed nginx, PHP5 on each EC2 instance.
external RDS MariaDB instance with 0.6GB RAM.
The mounted EFS shared file system that hosts /var/www has around 50Mbps disk throughput (burstable to 100Mbps according to AWS documentation).

Dominion

It feels a little faster now. (It's hard to say because my wife is hogging the internet.)

It wasn't really "sluggish" before ... just a little slower than I'd expect from a server in Japan.

viet

Dominion I changed the forum location to Japan. I really like this location for this specific website (because the target audience is Vietnamese & expats in Vietnam).

Just hope that I can autoscale a shared file system cluster if AWS doesn't release EFS in Japan.

Can you test and see how fast it load?

Dominion

A little bit faster. I'm seeing a latency of 40ms now, so the difference may be down to that, but ... I'm probably the wrong person to ask for help with such testing.

I live in a rural area, quite some distance from the nearest switching station, so my DSL line is slow at best and performance tends to vary a lot depending on the time of day, etc. (even when my wife isn't hogging the internet). So small differences tend to get lost in the general horribleness of my internet connection. 😛

I've been wondering ... Why not use the Singapore location? Is your audience in the US as well as SE Asia?

viet

Dominion Great thanks! 40ms is great.

Sometimes slow internet connection is great for testing Flarum's performance. 😛 If the software couldn't serve users with slow internet instantly, then something needs to change.

I don't like Singapore, because I also want to target United States people who are interested in Vietnam, and Vietnamese people who live in the US lol.

Dominion

viet Sometimes slow internet connection is great for testing Flarum's performance. If the software couldn't serve users with slow internet instantly, then something needs to change.

True! From that perspective, it seems to be working just fine. The other problem is that I'm not used to seeing how Flarum performs over SSL, so it just feels really slow.

viet I don't like Singapore, because I also want to target United States people who are interested in Vietnam, and Vietnamese people who live in the US lol.

I thought that must be what you have in mind. Tokyo's certainly a good location for that. 🙂

Simdol

Dominion

I've been using SSL with Flarum ever since I've started to use Flarum. I've noticed no performance differences in my opinion with or without SSL. I think it rather depends on the SSL negotiation in the web server side, not performance issue from Flarum.

What happens is that if you are using CloudFlare, while it does improve loading time, it does increase the initial page loading time due to website being proxied twice before getting to the visitor. While using other static CDN solution could solve those problems, I generally don't see a point in using CloudFlare if you are using AWS or other CDNs.

viet

Simdol Great question! For many peole and in many cases, CloudFlare isn't the best option. However, in my case, it is. I chosed CloudFlare because of the following reasons:

It's fast: The thing with CloudFlare and AWS is, they're in the same data center at many locations, including Japan. Both use Equinix as data center and use Equinix Cloud Exchange to communicate between each others (just like Google, Softlayer). Traffic from CloudFlare can use the fast pipe to go to AWS, and all of those traffic isn't necessarily routed to the internet but rather via private line. As a result, it is fast and secure.
Locations: Although my back end is in Japan, the closest data center from Vietnam to the website is CloudFlare's Hong Kong. In this case, CF helps tremendously in optimizing the traffic route, especially during normal day time when internet congestion usually occur in my city.
Security: I don't want to just use Static CDN solution and leave AWS ELB as front end because I don't want to get hit with DDoS attack. AWS ELB isn't going to save me from such attack. While with CloudFlare, I can mitigate small attack and if my site goes popular, I can upgrade the plan when I see fit.
Flexible SSL: I like how CloudFlare provide Flexible SSL and terminate it at CloudFlare level, so no performance hit on the backend instances here. There's no security risk because of the same data center with AWS, and it improves how SSL is handled.
Dynamic content caching: My site has CloudFlare Railgun enabled, which is a feature to optimize and cache dynamic content (dynamic content is cached via Memcached, ikr 🙂 ). While Akamai, Fastly and Cloudfront also support something like that, most only route dynamic content and not cache it, the one who does is expensive, I'd rather go with CloudFlare. Simply use the following command to test, you'll see the site usually achieves over 90% compression on both dynamic and static contents. It saves me bandwidth cost with AWS. Time to first byte is optimal so page load time is actually optimized and lower than if I go direct to AWS ELB.

for i in {1..15}; do curl -svo /dev/null https://viet.vn 2>&1 |egrep 'Cf-';done