One of the crucial steps in hosting WordPress on scalable infrastructure is picking the right type of VMs. Cloud providers don’t make this task easy.
Take AWS, for example. AWS EC2 has 277 different instance types. Azure and Google Cloud are not far behind either. Google also lets you design your own VM types with any number of CPU cores and memory. Google even allows you to select the CPU architecture for your instances.
Besides too many VM choices, another hurdle with capacity planning is anticipating the resources needed to serve traffic efficiently. More often than not, visitor traffic is a result of marketing campaigns and events like newsletter blasts, media appearances, or virality on social media.
At Scale Dynamix, we see this pattern regularly on busy websites. When a site serves 1,000,000 visitors in a day, 50% of those are in a span of 30 minutes; another 30% visits occur in 2 hours, and remaining traffic is spread throughout the day.
Real-world traffic patterns like this defy the capacity planning suggestions we often see on WordPress forums. Here’s a typical scenario I see on Facebook:
Person A: I have 200,000 monthly visitors and 200 products on my site. Will a 2 GB memory VM be sufficient?
Person B: 200,000 monthly visitors is roughly five visits per minute. Even a 0.5 GB VM will be too much for this.
While a 0.5 GB VM can serve five visits per minute, real-world traffic is rarely that orderly. When you factor in the overhead of backups, database buffers, logging, and monitoring, there is barely any room left for actual visitors.
On a busy WordPress site, visitors are not the only resource consumers. You also have writers, editors, order fulfillment services, image processing, reporting, and backups that are equally, if not more, resource-intensive.
So how do you pick the right server size for your busy site?
I like to assign CPU cores and memory to the functions the server is required to do and work my way up to traffic patterns.
Here’s an example:
OS basic functionality: 0.25 CPU 0.25 GB memory
Monitoring and WebOps: 0.25 CPU 0.25 GB memory
Backups: 0.5 CPU 0.5 GB memory
PHP: 1 CPU 1 GB memory per worker
Nginx: 1 CPU 1 GB memory per worker
MySQL: 1 CPU 1 GB memory per 0.7 GB of database
Add these up, and you get the base configuration necessary to run your site efficiently. Depending on the traffic patterns, you can either select verticle or horizontal scaling.
With verticle scaling, your goal should be never to exceed 75% of allocated capacity. This provides a buffer against sudden traffic spikes and WebOps overheads.
An adequately designed horizontal scaling cluster separates the web, php, and the database servers across different VMs. Making sure that the individual web and php instances have enough CPU capacity helps minimize any latency or lag on the frontend.
No matter which solution you pick, make sure you are monitoring critical metrics and have ample safety buffer in place to handle the traffic spikes while new instances are spinning up. Eventually, you will have the right balance of capacity and performance without any wasted resources.