We have a passion for high performance. Going beyond default server configurations to get the most performance out of your servers…so you don’t have to!
Increasing Performance with Concrete5
Concrete5 is an open source CMS for creating and publishing websites. It’s been designed for ease of use and is geared towards users with minimal technical skill.
Concrete5 has been a long time Liquid Web customer and partner, and we recently had a discussion around improving Concrete5 performance when hosted at Liquid Web. We spent a few months tweaking and tuning our servers (mainly our fully managed cPanel template), and have come back with some pretty exciting news, Concrete5 is now significantly faster than before, at least on our cPanel template!
In this blog, we will discuss the before and after performance of Concrete5, running on Liquid Web’s Storm Platform. I’ll cover what performance looked like with our “old” cPanel template, then I will compare that to our latest optimized cPanel template, and will explain how we were able to increase performance without even touching Concrete5 code.
This means that you can have the same level of performance that is outlined in this post, no work required.
What are we measuring?
Today we will be looking at Concrete5 performance and how it’s affected by the cPanel optimizations we have implemented. Everyone knows that the server hardware used can have a large impact on CMS performance, but what about the server software and it’s configuration?
To isolate the difference in performance I will leave Concrete5 alone in terms of configuration, at least for now. Once we know the difference between the old and new template we can start to tune Concrete5’s built in caching settings. I’ve found that measuring one step at a time is the best way to understand why performance is how it is.
We will be focusing on a few different metrics that relate to Capacity and User Experience. I like to split up performance testing into these two categories as it helps to isolate metrics that are most relevant to the business and end user.
Businesses want to be sure their website remains online even if there is a flood of new users or traffic.
End users want to experience almost instant page load times, no one likes waiting 10 seconds for a page to load.
Capacity tests involve pummeling your website with as many requests as possible until it falls over and dies, or at least becomes unresponsive. This may sound cruel, but you need to know what the limits are before you put your site in front of billions of people. The name of the game here is:
- Requests per second – How many requests can a web server can handle in a given second?
- 95% Response Times – The amount of time that 95% of requests complete under.
We will be using LoadStorm and Apache Benchmark to run our capacity tests. While these two tools are more or less doing the same thing, I always like to run a few different tools to either confirm the results/trends or to spot inconsistencies in the test results. Measuring twice never hurt anyone.
User Experience tests involve analyzing your website’s content and how it interacts with the end user’s browser. Just because your server can handle 9001 requests per second doesn’t mean your end users will experience a fast and responsive website (unless you use our newly optimized cPanel template that is).
The metrics we will be looking at here are:
- Page Load Time
- Time to First Byte (TTFB)
- Best Practice Scores (First Byte, Keep-alive, Compress Transfer, Compress Images, Cache Static Content, Use CDN)
To measure these things we will be using my favorite tool, WebPageTest. When running WebPageTest I changed the number of runs to 9, then recorded the median result, this provides more consistent results than running a single test and reporting those results.
Specs and Test Info
For these benchmarks, I created two identical SSD VPS, one with the old template installed, the other with the new template installed. Both servers have the specs below:
- Platform: Liquid Web Storm
- Server: 4GB SSD VPS in Zone C
- vCPU: 4x Intel E5-1650 v4
- RAM: 4GB
- Storage: 300GB SSD Storage backed by Hardware RAID 10
- OS: Fully Managed CentOS 7 with cPanel (the old version and new version)
If this server looks like a great choice for your business, see our VPS lineup today.
Concrete5 was installed using Softaculous which comes installed on all our cPanel servers for free! I created both test installs with sample data so there was at least some content to hit when running the benchmarks. At the time of writing this Concrete5’s latest version was 8.1.0.
I left all Concrete5 settings at their defaults for this test. No special optimizations were done inside of Concrete5, at least at this time. This means that things like “Full Page Caching” are disabled for the initial tests.
The “Old” cPanel Template Specs
I’ll be testing out the old cPanel template and the new, optimized cPanel template in this post. Any Liquid Web server that was “kicked” or created before June 2017 will be using our old cPanel template.
The old cPanel template used the following stack:
- PHP 5.6 with FCGI
- Apache 2.4 with Event MPM
- MySQL 5.6
- cPanel’s Easy Apache 3
At the time this was the best stack available on cPanel (at least from what I tested). This stack still performs well today, so if you are still using the older template don’t feel too bad. If you would like to hop on board the latest and greatest, please open up a support ticket and we will get you moved over!
The New cPanel Template Specs
Any server created after June 2017 will be using the latest, optimized cPanel template. The new cPanel Template uses the following stack:
- PHP 7.0 with FPM
- Apache 2.4 with Event MPM
- MariaDB 10.1
- cPanel’s Easy Apache 4
So what all did we change the old and new cPanel template? Lots of things! I won’t get into the nitty-gritty in this post, but the TL;DR change list is:
- Updated the default PHP version from 5.6 to 7.0. The latest version of PHP is much faster than previous versions, at the same time it uses less memory. More performance, less resource usage!
- Updated the default PHP handler from FCGI to FPM. You can run PHP a few ways, up until this release the best option was FCGI, which works OK for the most part, but is rather dated. With cPanel EA4 we can now utilize FPM, which is faster and more efficient than FCGI.
- Updated MySQL 5.6 to MariaDB 10.0. We’ve moved to the latest supported release of MariaDB which offers various performance and stability improvements over MySQL 5.6.
- Added .htaccess directives that enable browser caching and compression by default
Alright, enough talking about the old and new template and the differences between them. Let’s get to the benchmark results.
I did not create any extra content before running benchmarks, and used the homepage for all tests. I did not simulate logged in behavior, only “get the homepage”. While this scenario is not perfect, it’s a simple way to get a baseline on performance before running more complicated tests.
For the Apache Benchmark test, I spun up a VPS on the west coast and ran AB from that server. Both of the VPS’s running Concrete5 were located in Liquid Web’s Zone C, which is located in Lansing Michigan. I specified 200 concurrencies and a total of 5000 requests for the test runs.
As you can see below, the new cPanel template is able to serve up our Concrete5 test site 170% faster than the old template! A lot of this is due to PHP 7 and the introduction of PHP-FPM, which significantly reduce the amount of CPU time needed to read, interpret, compile and execute PHP scripts.
Not only are we able to handle more requests per second, we are also able to serve each request much faster than before. More throughput, lower response times, that’s what I’m talking about!
With the previous cPanel template we see that 95% of requests completed in under 41 seconds, or 41,000 milliseconds. This is a painfully long time, even if the server is handling 200 concurrent users.
The new cPanel template offers much lower response times, 95% of requests completed in under 7 seconds, this is about 500% better than the old template. While 7 seconds still seems like a high response time, keep in mind this is under extreme circumstances, most websites will not see 200 concurrent users requesting the same page at the same time, unless you are getting DDoS’d or get linked to on HackerNews (the former is not good, the latter is good, as long as you are prepared).
Apache Benchmark shows that Concrete5 can handle 170% more requests on our new cPanel template, at the same time the response time of those requests is 500% faster. That’s a pretty solid gain considering we are using the exact same hardware for the old and new template.
Again, full page caching was not enabled in Concrete5 for this test, so results here are “worst case”, or “out of box”.
Next up is LoadStorm, which offers a decent amount more features compared to AB, specifically the ability to simulate transactions, or multi-step scripts. In this case I created a simple script that opened each site’s homepage. I chose USA locations only, ran the test for 6 minutes, capping out at 300 users for the last 1 minute of the test.
As you can see below, the new cPanel template shows an increase of around 150% in terms of peak requests per second. Because we are testing from multiple locations in the US and using a higher number of virtual users we see higher results than we did with Apache Benchmark, but the trend is almost identical.
Now that we know the new cPanel template offers improved Concrete5 performance over the old template, let’s take a look at how this affects what really matters, end-user / browser performance!
WebPageTest is an amazing tool. It’s free, it gives you useful info and generally speaking it offers consistent results (if you set test runs to 9 instead of 1). End users do not care how many requests your server can handle, they only care about fast website load times. No one likes spinning wheels and most people don’t wait much longer than a few seconds before they move on to another site that loads faster.
The new cPanel template shaved 200 milliseconds off of page load time. Relatively speaking this isn’t a huge gain, but 200ms is 200ms, load a page 5 times and you just gained 1 second to do whatever you want to do with!
While the page load time improvement was minor, the improvement in first byte response time was a lot more dramatic. First-byte time is the amount of time it takes for content to start displaying/rendering in the browser. This metric is more important than total page load time (at least in my opinion) because users tend to stick around if they see progress or any kind of content they can begin to read.
Concrete5’s first-byte time is almost half of what we see on the old template! Most people agree that aiming for a first-byte time that is close to or under 300 milliseconds (or 0.3 seconds) is best practice.
As far as best practices go, here’s what Concrete5 looks like on the old template:
If this website had parents, they likely wouldn’t be thrilled about the C or the F (at least my parents were never thrilled).
The new template provides much better “grades” out of the box, even my own parents would be proud to see this many As!
The only thing missing here is the use of a CDN, but I left that out intentionally for the sake of this article (don’t worry, follow up CDN posts will be a thing!). In the meantime, check out Liquid Web’s CDN offerings!
Looking over the results it’s safe to say that our new cPanel optimizations offer a pretty sizable performance improvement over the old template, at least when running Concrete5.
Not only do we see faster response times and higher throughput, we also see an improvement in the amount of website best practices that are implemented by default.
If you are running Concrete5 today, wouldn’t you like it to run a little faster? At Liquid Web we believe you can always make something a bit faster, and you don’t always have to spend more money to get better performance.
Our new cPanel optimizations certainly seem to improve Concrete5 performance!
What do you think? If you feel like there is room for more optimization, or would like to see other CMS covered, let us know.
Want to partner with the fastest, check out our partner programs.
Mike was the former Senior Solutions Engineer at Liquid Web. He likes to keep an eye on the Internet, measure it, and make it go faster. He won't accept "ok" performance, and doesn't think you can ever have "too much" performance.
Keep up to date with the latest Hosting news.