Handling traffic load with WordPress

“What if my WordPress site gets a rush of traffic, maybe I’m featured on a huge website or even TV?” – it’s a question we’re asked many times. With the virality of social media and more this is a real concern for many users, and maybe one day, your own website.

With several of our legacy shared products the answer to the question has always been an awkward mix of maybe, perhaps and then a lot of crossed fingers. Shared hosting by its very nature can skew from awful to amazing dependent on many factors; many of which are out of the end clients control. How loaded is the server, what are other clients doing right now, what will they be doing in an hours time, what cron might kick in four hours from now, and on and on.

With our new WordPress hosting platform running optimised containers, this is no longer the case. Isolated containers immediately take away many of shared hosting’s limitations – the action of other users on the system being a huge one.

Moreover by just hosting one application, WordPress we can make micro adjustments at all levels of the hosting stack with that in mind. Containers offer the ability to configure items like the webserver, caching, database and more with fine granular control. For example some of our recent improvements to the WordPress platform for all users include:

Tweaking the configuration used by our container provisioning software, to make sure that all services in the container are able to make use of the total allotted amount of memory in the container and that when extra memory is allocated it is available straight away.

With containers, we can specify a number of virtualised CPUs these behave just like the CPU in your machine, at least from the containers perspective. Going from 2 to 4 CPU per container is massive improvement in processing performance.

The WordPress containers have a generous 2GB of RAM on our default package, and so we are able to provide more resources to PHP-FPM and similar services, previously we kept the amount individual services low, to maintain stability of the container. However our initial limits were perhaps a little to conservative so we have taken the reigns off.

We have made specific tweaks to PHP-FPM, to dynamically increase the number of workers, to take the strain when the site comes under load. Each site has 2 workers which are dynamically generated, with up to 8 within the container. So an individual site has the ability to spin up additional workers, without impacting other sites on the container. We also changed the way we handle waiting for PHP-FPM to respond, so that Nginx is willing to wait during slow periods.

Finally with the reigns off and with the tweaks we are able to massively increase the max number of connections both Nginx and PHP-FPM are able to accept.

Each tweak means the system is more capable of responding to dynamic and sustained load. And its that very type of event that 34SP.com client, Andrew Shanahan has experienced more than once. Indeed his website MAN v
FAT recently encountered such a situation:

“This has happened a few times. I run a very popular men’s weight loss website which helps guys around the world. As a result we get a lot of PR requests. As a result of our latest scheme MAN v FAT Football we were asked to be on the BBC’s One Show, which has over 6 million viewers. I’ve done the show before and I’ve seen what a stampede of traffic can do to a website – and it’s not pretty.”

As much as we can pre-optimise and configure a website to cope with load, we can always do more – much more. Andrew prudently dropped us a note with his impending TV appearance top of mind, so we could triple check his website setup:

“Before we went on I sent a tech support request to 34SP.com who replied that they would take care of it. I’ve learned that with 34SP.com if they say they’re taking care of something then I can relax. This was especially useful as it meant that I could focus on the programme and let you guys take care of the site.”

Every WordPress website is unique, with its own set of plugins and configurations, but our team are always ready to advise. With the note from Andrew that his site was about to be hit hard, platform developer Phil Barton ran the rule over the container:

“On finding out MAN v FAT was going to be on TV, initially I took a look at the site and ran through all dynamic content and forms to ensure everything was working properly. I then checked over the hosting platform, looking over things like Memory allocation, Hard disk space, CPU resources to ensure everything was working correctly from the back end.

Everything looked fine with the changes listed above, so at that point we increased the slice allocation to 6 units which automatically increased the number of php-fpm workers, and the amount of memory to the container to handle the extra workers. We also made a one-off change to the Nginx configs to ensure the home page was being cached – as a plugin was bypassing the cache with a php session.”

The extra resources proved to be extraneous in the end, but we wanted to take zero chances. Indeed, we didn’t even bill Andrew for the brief resource bump – our goal is to be ready and waiting for when our clients need us.

And Andrew’s experience, in his own words? “I knew it would be ok and it was – the site got hit pretty hard but all of the preparations meant that the site coped with the traffic brilliantly.”