Managed WordPress Hosting Update

With WordCamp London just around the corner and our Managed WordPress Platform sailing out of beta, now seems like a good time to update folks on the changes over the last few months.

Since mid January our existing WordPress Hosting clients have been on V2 of our stack and it’s changed quite a lot even since we migrated them.

Introducing V2 of WordPress Hosting Platform

V1 of the WordPress hosting stack resembled a pretty common variation in the managed WordPress space: Apache, MySQL, PHP and Varnish with memcached also running behind the scenes. This setup works well on managed WordPress hosts who are using a shared environment across their clients. It allows them to give the performance everyone expects at a reduced cost by increasing the number of sites on a single piece of hardware.

Even with V1 of our stack we were doing things differently and were using virtual private servers to give containers for every client. This meant we were running Varnish inside the container and clients had separated resources. The results were good, but Varnish is a resource hog and this meant we couldn’t get the most out of the containers.

When it came to redesigning the stack, we first looked at each component in isolation and tested with various replacements. For example we looked at Nginx and Apache to see what resources were used, load times and concurrency. While all the research and our experience elsewhere showed Nginx would out perform Apache we were blown away by the real world results when partnered with PHP-FPM. We took the opportunity to make other changes in the stack such as swapping from MySQL to MariaDB.

One area we didn’t change was Memcached. We looked closely at the resource usage, requests and features of Memcached and Redis. While Redis did perform as well and in some tests exceeded Memcached it was not as significant as expected. While other systems we use do use Redis, the team’s familiarity with Memcached meant it was logical to leave Memcached as the application cache.

When it came to Varnish, we did not expect to be swapping, but it quickly became clear that for the type of caching we required, Nginx FastCGI cache was just as quick, used significantly fewer resources and all with fewer moving parts, making it a lot easier to maintain.

Our resulting stack since January has been 2GB VPS containers, with virtualised quad core processors, 25GB disk space running CentOS 7. Nginx is our HTTP server, with FastCGI caching, mod_pagespeed & mod_security modules enabled. MariaDB and Memcached provide database and application caching for WordPress.

We have continued making enhancements; even after the stack was launched in January we have been making improvements and over the last couple of months have seen a 20% improvement to page loads on uncached content while doubling the number of concurrent users able to access the same content.

New Platform, New Features

Along with the new stack has come a range of new features. The one we are most excited about is the free SSL certificate being provided by Let’s Encrypt, meaning every site on the platform can benefit from end to end encryption with one click. It also means that with the same click of the button, every site can now receive a substantial performance boost by leveraging HTTP/2 and all sites running SSL, be it through Let’s Encrypt or their own SSL certificates run by default over HTTP/2.

From day one we wanted every site on the platform to be running over SSL. Indeed we experimented with automatically creating certificates and setting up SSL without any request from clients. Sadly there are too many obstacles to make that happen which would prevent clients access to their new sites in minutes rather than days.

With the one click button directly in the WordPress control panel thanks to 34SP.com Developer Tools we have seen 46% of active sites on the stack enable Let’s Encrypt. A further small percentage of clients bring their own certificates or use one of our EV certificates, meaning close to 50% of clients on the WordPress Hosting platform are using SSL and HTTP/2.

staging-pushpull

Another area we are pleased to see clients using is the new staging site feature. Through the 34SP.com client control panel, WordPress Hosting clients can access staging sites for each of the sites on their containers. With a single click a staging area can be created which is an exact replica of the live site. From the staging site, content and files can be pushed and pulled between the staging site and the live site. This allows clients to test changes safely in the staging environment before pushing to the live site.

The last few months have been hectic, we’ve have had some great success stories and a few hurdles. We have seen the Aegis security suite thwart attacks, that in turn assisted our team to help mitigate a recent spate of XML-RPC attacks on other systems.

We have worked with our systems team to ensure containers are PCI compliant – opening the way for e-commerce hosting through WooCommerce and similar plugins.

We seen page load times tumble. Some of our larger (in terms of page weight) sites have seen page load times drop by, in one case, over 10 seconds after moving to the platform. Clients are also gaining the benefit of automatic updates, meaning they can concentrate on creating their great content and let us worry about what’s going on behind the scenes.

V2 is now coming out of beta, but that doesn’t mean we are stopping work, if anything the road map continues to increase. If you are at WordCamp London, come along to our stand, meet the team and find out what we have planned in the next few months.

Tim Nash

Tim is a well known member of the WordPress community and a regular attendee of our local Manchester WordPress User Group as well as being a co-organiser of the WordPress Leeds user group (the oldest in the country). He is also an established speaker at WordCamps and tech conferences both in the UK and abroad.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment