Is a Load Balancer Overkill in Your WordPress Hosting Setup?
What is Load Balancing?
Before discussing whether a load balancer is needed, we should ensure that we’re all on the same page when it comes to understanding the function of a load balancer. In its most basic form, a load balancer is a server that distributes network traffic to a series of backend servers. It does this using a few different algorithms, but commonly uses round-robin or least connections:
- Round-Robin – Requests are distributed between the backend servers sequentially.
- Least Connections – New requests are sent to the backend server with the fewest current connections.
By distributing network traffic to a pool of backend servers, you can dramatically improve concurrency. In the case of WordPress, this is the number of concurrent users your site can handle. Let’s look at a typical server setup geared towards WordPress:
In a load-balanced setup, we extract the various server components to their own dedicated servers, resulting in a setup similar to this:
This load-balanced setup introduces a couple of benefits:
- Each server has fewer responsibilities, meaning that they usually have fewer software packages installed. This often results in each server being more efficient because their CPU cycles are reserved for a single task. In a single server setup, Nginx, PHP, and MySQL will all be fighting for CPU time to handle a request.
- Each part of the system can be scaled independently of the other. If your database server is the bottleneck, you can increase the size of the database server or add additional replicas. Likewise, if your app servers can’t handle the concurrency, you can add more app servers.
However, a load-balanced setup isn’t without its drawbacks:
- It’s costly. The act of extracting each server component to its own server means that you will be paying for more servers.
- It’s more complicated. Handling a single web request involves a lot of moving parts, and those parts are only increased further as you add more servers. You can alleviate this problem somewhat by opting for managed services, such as managed database servers or load balancers, but this will further increase costs. Likewise, AWS offers both managed databases and load balancers.
With that out of the way, let’s look at a few common load balancer misconceptions and perform some benchmarks!
Load Balancing Misconceptions
Instant Performance Win
Throwing a load balancer into your hosting setup won’t instantly boost application performance or throughput. That’s because when you split your application services across multiple servers, you introduce network latency. Even when your servers are located in the same data center, a series of network connections must be made to handle each request. Typically, your application servers will need to communicate with your database and object cache servers.
To see a performance gain, your existing single server setup will need to be under strain. Meaning, if your current server is happily sitting at 20% utilization, load balancing will probably be marginally slower per request. However, once you reach a level of concurrency that your single server is unable to handle, throughput will start to decrease and response times will increase. We can test this for ourselves using Loader, which is an application load testing tool. Here, I’ve provisioned a 4 GB RAM, 2 vCPUs server on AWS Lightsail using SpinupWP. I’ve deployed a single site to the server with HTTPS enabled, page caching disabled, and Redis object caching enabled. I’ve then tested the site over 5 minutes, with a concurrency level that grows from 1 to 50 users:
For the load-balanced configuration, I’ve deployed the following setup using Amazon Lightsail:
- Amazon Lightsail load balancer
- App servers – 2 x 4 GB RAM, 2 vCPUs servers
- Object cache – 1 GB RAM, 1 vCPU server
- Database – 4 GB RAM, 2 vCPUs managed database
The app servers are provisioned using SpinupWP but have had both MySQL and Redis removed. The object cache server has nothing but Redis installed. Once again, I’ve deployed a single site to the server with HTTPS enabled, page caching disabled, and Redis object caching enabled. However, HTTPS termination is handled at the load balancer, not at each app server. I’ve then tested the site over 5 minutes, with a maintained client load from 1 – 50 (as above):
The average response time is much lower on the load-balanced configuration (306 ms compared to 533 ms). However, the single server outperforms the load-balanced configuration until around 8 concurrent users.
Auto-scaling is the ability for your server infrastructure to scale up or down based on concurrent requests. This can help to limit some of the costs involved with running a load-balanced configuration, by only having enough servers standing by to handle the current workload. Without auto-scaling, your infrastructure would need to always run with the capability of handling peak traffic.
Load balancing isn’t auto-scaling. However, load-balancing is required in an auto-scaling infrastructure. Just because you have a load balancer installed, your stack isn’t going to grow as concurrency increases automatically.
High availability is another buzzword often thrown around, which usually means 100% uptime. This is a common requirement for business-critical sites, such as busy e-commerce stores. Similar to auto-scaling above, load balancing alone doesn’t grant you high availability.
Like in a single server setup, there are still multiple points of failure in a load-balanced configuration. For example, if a single app server were to fall over, your site would likely continue to work (because there are other app servers available to take up the slack). However, the load balancer itself, database server, and object server often remain a single point of failure. You can somewhat alleviate this issue by opting for managed services (as mentioned above). Both Amazon Lightsail and DigitalOcean offer managed database servers with high availability options, but you will pay a premium for the added redundancy.
What You Should Do Instead of Load Balancing
Load balancing certainly has its place when it comes to high-traffic WordPress sites. However, load balancing shouldn’t be the first solution you reach for when ensuring your WordPress site can handle significant traffic.
First, you should ensure your site is correctly cached by following our guide on caching: WordPress Caching: All You Need To Know. If page caching isn’t an option or you’re still hitting scaling issues, it’s time to look at vertically scaling your server hardware. Sometimes, simply adding an extra CPU core or a few GBs of memory can have a profound impact on your site’s ability to handle load. Once you’ve exhausted those avenues, then is the time to reach for load balancing.
Have you implemented load balancing? Let us know what challenges you faced in the comments below.