Scaling WordPress: The Autoscaling Fallacy

Busy sites need autoscaling. That’s what everyone expects, technical and non-technical users alike. The rising popularity of cloud computing has taught us to expect unlimited capacity for all online services.

How does this apply to WordPress?

A quick search returns hundreds of results that equate AWS with automatic infinite capacity. While AWS is no silver bullet, some of these results do recommend a scalable architecture.

How does autoscaling actually work in the real world, though?

In theory, an adequately configured stack keeps track of various resources, such as CPU, Memory, PHP workers, etc. When the utilization for any of these resources exceeds a predefined limit for more than a few minutes, stack launches another VM. This new VM is then used to serve the additional traffic. Stack repeats this process as long as there is enough traffic to warrant additional resources.

Pretty cool, right?

While this process looks great on paper, it’s a little less magical in reality. When the stack launches a new VM to serve additional traffic, it can take 60 to 120 seconds for it to become ready and join the load-balancer. A good web ops team knows this and utilizes various caches and queues to make this latency invisible to the end-user. Without such caches and queues in place, visitors experience timeouts, slowdowns, or random errors while new VMs are being prepared.

Since autoscaling requires sustained heavy traffic to launch new VMs, it makes little sense to use it on smaller sites.

Time for a car analogy.

F1 cars are built for massive speed. But if you try diving an F1 car on slow speed, it doesn’t generate enough downforce to provide decent traction, the breaks aren’t warm enough to be useful, and the handling is tricky at best.

To get around some of these issues, the F1 crew pre-warms the tires, uses a starter motor to start the engine, and has the skills to handle any pit stops as quickly as possible.

When it comes to operating an autoscaling environment for WordPress, you do need similar systems in place. A process to warm up the load balancer, a way to spin up additional VMs, and a star crew that maintains the pit stops. There are just too many moving parts for autoscaling to “just work” automatically.

When you are shopping for an autoscaling solution, ask the providers on your shortlist these questions:

What’s your plan to minimize the latency while new VMs starting?
Will I be able to launch more VMs in advance if there is not enough traffic yet?
Will I be able to control the thresholds when autoscaling launches additional VMs?

And finally,

Will I be able to contact the crew that set this up directly when I’m expecting a traffic surge?

These questions will help you look past the marketing speak and save a lot of stress down the line.