One of the first areas we turned our attention to in building the best WordPress hosting experience was performance. As I mentioned in my previous WordPress Hosting post, one of the biggest drawbacks to shared hosting is the inability to tweak and tune the hosting environment for just one purpose. This in turn can lead to slow sites, sluggish load times and less than happy clients. These are three things we never want to see. In creating our new managed WordPress platform, nothing was off limits; we considered anything that might wring every last drop of speed out of the new hosting setup.
VPS with SSD
We wanted to start with solid foundations, and looked at the hardware first. You’ll probably see SSD drives touted all over web host product pages these days, but it’s just marketing fluff. The cost of these drives continue to drop and the performance leap over traditional magnetic drives is profound. I’ll spare you the graphs and charts here, Google is full of comparative information. At any rate our new WordPress platform is provisioned with 100% SSD storage to load pages at the fastest speeds possible.
We also over provisioned the RAM a tad too. Each VPS is allocated 2GB of RAM which in truth is substantially more than most sites need. We wanted to do this to ensure our raft of caching software had enough footprint to really work its wonders. Speaking of which…
Varnish is caching software that we install as standard on every new WordPress account. Varnish is awesome. Like waking up, dreading the work commute, then realising it’s Saturday. And your birthday. Yep, full of win.
When a visitor hits your website, Varnish takes a copy of the page served and stores it. If a second visitor comes in and asks for the same page, Varnish will directly serve this up, rather than ask your WordPress account to recreate the whole page from scratch again. By avoiding the dynamic recreation of pages for every single request, the stress and strain on the hosting server is hugely reduced.
This approach helps massively for sites that experience sudden and dramatic spikes in visitors. Did Stephen Fry just re-tweet you? Are you seeing hundreds of users per second? Chances are they’re all asking for the same page, and Varnish shines here by caching high demand pages and serving them up at ultra quick speeds.
We also configure Varnish so that if you’re logged into your WordPress admin pages, the cache won’t affect your usage of the site; if you make a change, you will see it in real time. We also provide a cache purge button too, if you need to reset Varnish for any reason.
Memcached and PHP OPcache
RAM is always quicker to access than disk space, even when using SSDs. The more items of a website that can be retrieved from RAM as opposed to disk, the quicker the site will run. With this in mind, backing up Varnish are these two other components that help to cache two other important elements that make up WordPress page requests.
Memcached caches various parts of the MySQL database in memory saving precious database lookup time for certain pages. OPcache improves PHP performance by storing compiled bytecode in RAM – meaning that certain scripts don’t need to be compiled over and over on every single page request.
But that’s not all. When CloudFlare serves your content to your site visitors, it performs a number of on the fly optimisations. From compressing certain types of content to minimizing network connections to the end user, CloudFlare makes sure your content is being served in the fastest, most streamlined way possible.
We also activate the Mirage image optimizer too – a feature CloudFlare only provide in their paid plans. Mirage works by optimising your website’s images for the end user’s device. This makes websites hosted on our managed WordPress platform immediately faster on mobile devices and networks.
Show me the money
O.k. so what does all of this mean? Sure it sounds great on paper, but what are the real world implications of all this? We had a vague goal of wanting to power millions of page views per month, because well, millions of things are pretty fun. Beyond that we didn’t know, which is where our load testing and QA process kicked in.
We decided to use loader.io, a popular tool to load and stress test web applications.
Our test site was a real world website of one of our team members here at 34SP.com. The test site was greater than 1GB in size, had 17 plugins and more than 20 authors who’d created 250+ posts in the past year. While every site is built differently and has different load demands, we felt this site represented a decent example of a typical WordPress site.
The load testing tool pretends to be a real user and requests a page from the site randomly. It then times how long the host takes to respond and return each page (response times) and if any of the requests fail (error rate). We kicked things off with a modest 50 connections per second and these were the results:
Pretty good stuff. As the graph moves from left to right you can see the green line indicating the number of connections per second and the blue line showing the response time for the requests. Overall, 3000 pages served in one minute, and zero failures.
Happy with that, we took things to the next level, 250 connections per second, here’s what we saw:
Wow – even better results. While this might seem to be counter-intuitive at first, it shows that the advanced caching and CloudFlare network are picking some of the extra load up. Varnish will have cached a certain percentage of the page requests and therefore the average response time will drop as every request isn’t being dynamically created by WordPress. And again, 15,000 page views over one minute, no errors.
We’d be happy just there, but we wanted to see how far we could push the platform. So we went to 1,000 connections per second, here’s what we saw:
60,000 connections in the space of just one minute, and zero failures. The response time now starts to creep up, but 200ms (0.2 seconds) to return a page request on average is hardly sluggish. Also bear in mind that many managed WordPress providers cap their monthly page view limits at far less than 60,000 a month, let alone per minute. Our goal is to have no cap on page views.
At this point we started to worry that our testing was configured wrong or we had missed some fundamental element. After all, 1,000 page views per second is hundreds of millions of page views per month at a constant rate.
We decided to push our testing tool to the very limit. Indeed, loader.io set a limit of 100,000 connections over a one minute period, so we went ahead and ran that test:
Here we start to see the limits of the hosting plan, as the error rate starts to go above zero, about 5% all said over one minute. Keep in mind though, this is our base plan out of the box, for just £14.95 per month. We are currently planning to offer an upgrade of just £7 per month that doubles the server’s resources, and in turn offers more oomph.
Wait, that’s not it
We’re continuing to fine tune our WordPress platform, and already have plans to improve performance further. For example – while some managed WordPress providers are currently offering HHVM to speed up PHP – we’re waiting for the release of PHP7 which is just around the corner. In PHP7, native PHP execution performance is starting to look comparable to HHVM and we’ll be offering that as a drop in upgrade for free, sooner than later.
In my next post, I’ll be looking at another important element of hosting WordPress – security – and how we’re looking to deploy sensible precautions on the new plan.