Scaling and High Availability

There are two ways to add capacity. Vertical scaling gives the existing server more CPU, memory and faster disks. Horizontal scaling adds more servers and spreads the requests between them.

The Advanced Administration Handbook gives the same order: caching and single-server tuning first, then the database on its own server (a change of DB_HOST), then offloaded static files, and only then load balancers and several web servers. An edge cache absorbs anonymous page views; horizontal scaling is for the uncached work that remains, such as logged-in editors, comments, search, the REST API, admin-ajax.php and a shop’s cart and checkout.

The edge cache serves anonymous visitors and static files. The load balancer (two instances, or a managed one, so that it is not the new single point of failure) terminates TLS, adds X-Forwarded-Proto and X-Forwarded-For, and stops sending requests to failed nodes. The identical, stateless web nodes can each serve any request and be replaced at any time. One scheduler runs cron events. The shared services are the uploads store, the object cache and the database, with a primary for writes and optional read replicas.

The same topology as a managed cloud design, with the database on RDS or Aurora and the web nodes as pods on several EKS nodes, is in Cloud Reference Architecture.

A node is stateless when nothing that matters is stored only on that node. By default, WordPress breaks that rule in several places:

WordPress decides whether the current request is secure with is_ssl(). That function checks only the request as PHP sees it: $_SERVER['HTTPS'] set to on or 1, or $_SERVER['SERVER_PORT'] equal to 443. When the load balancer terminates TLS and forwards plain HTTP to the nodes, PHP sees an HTTP request on port 80, and is_ssl() returns false even though the visitor used HTTPS.

The symptoms depend on the configuration. With FORCE_SSL_ADMIN set, wp-login.php and wp-admin redirect to the HTTPS URL forever, because each redirected request still arrives at the node as HTTP. Without it, the site may build some URLs with http:// and the browser blocks them as mixed content. Logins can also fail silently, because the secure admin cookie is set only on requests that WordPress sees as HTTPS.

The Advanced Administration Handbook’s fix is to let wp-config.php trust the X-Forwarded-Proto header that the proxy sets, and to copy it into $_SERVER['HTTPS'] before WordPress loads. The handbook snippet reads the header without checking that it exists. Under PHP 8 that logs an "Undefined array key" warning on every request that does not come through the proxy, such as WP-CLI or a health check on the node itself. The version below adds the check:

Source: Advanced Administration Handbook: HTTPS (Using a reverse proxy)

The strpos() check also accepts a comma-separated list such as http,https, which some proxy chains send (checked under PHP 8.4: no header and http leave HTTPS unset; https and http,https set it to on).

Two security rules come with this snippet. First, the header is only trustworthy if the load balancer replaces any X-Forwarded-Proto that the client sent, as nginx’s proxy_set_header does. A proxy that appends to the client’s value lets an attacker add https to the list. Second, the nodes must accept traffic only from the load balancer, by firewall or private network, so that nobody can reach a node directly with a forged header. The official wordpress Docker image already contains the same guarded check in the wp-config.php it generates, so containers built from it need no extra code.

The visitor’s IP address has the same problem: $_SERVER['REMOTE_ADDR'], recorded for comments and used by security plugins, is the load balancer’s address. Fix it in the web server with Apache’s mod_remoteip or nginx’s realip module, which trust X-Forwarded-For only from the proxy’s address. Copying the header into REMOTE_ADDR in wp-config.php without that check lets any client choose its own IP address.

The following Compose file runs the topology at small scale: two WordPress nodes behind an nginx load balancer that terminates TLS, one MariaDB server, one shared uploads volume, and a cron runner. Each node keeps its own copy of the code in its own volume, as separate servers would. Only wp-content/uploads is shared.

Source: Docker Hub: wordpress (Docker Official Image)

The .env file next to it holds DB_PASSWORD and the eight WP_*_KEY/WP_*_SALT values. Generate them once, for example from https://api.wordpress.org/secret-key/1.1/salt/, store them in the team’s secret manager, and never commit them. The user: "33:33" lines matter: the CLI image is based on Alpine, where www-data is user 82, while the Apache image is based on Debian, where it is user 33. Without the override, files written by WP-CLI into the shared volume would not be writable by the web nodes. The lumenpress.test network alias lets containers reach the site through the load balancer by its public name.

The load balancer configuration, lb/default.conf:

Source: nginx: ngx_http_upstream_module

Round-robin is the default; least_conn; in the upstream block suits requests of uneven cost. Without a shared zone, a resolver and the resolve parameter (open source since nginx 1.27.3), nginx resolves web1 and web2 once at start-up and misses the new IP address of a replaced container until it is reloaded. With the configuration above, web2 was recreated and got its share of requests without a reload. Open source nginx detects failures passively: after max_fails failed attempts a node is skipped for fail_timeout, and proxy_next_upstream retries the request on the other node. Active health checks need HAProxy, nginx Plus or a cloud load balancer.

The certificate is a self-signed one for lumenpress.test (openssl req -x509 ...). That is why the curl checks below use -k. Production uses a certificate from a public CA. Install the site once, through the cron container because it has WP-CLI:

Source: WP-CLI Commands: wp core install

WP-Cron is triggered by page loads. On every request that finds a due event, WordPress sends a non-blocking loopback request to wp-cron.php. In a cluster that means every node spawns cron, the loopback goes back through the load balancer, and only the doing_cron transient prevents overlapping runs. It is also late on quiet sites, and it spends capacity on the very requests a spike sends. The cluster design is:

Source: WP-CLI Commands: wp cron event run

WP-CLI’s wp cron event run calls each due event’s hook directly. It does not take the doing_cron lock that wp-cron.php uses (checked in the WP-CLI 2.12.0 cron-command source), so two schedulers running at the same time can run the same event twice. That is the reason for a single scheduler, not one per node. Requesting https://lumenpress.test/wp-cron.php from an external scheduler is the alternative when WP-CLI is not available. That path does take the lock, but it occupies a web worker for the length of the run.

On the staging cluster, an event scheduled for "now" was not run by three page loads, and within a minute the cron container ran it:

Source: WP-CLI Commands: wp cron event schedule

The scheduler is itself a single point of failure, but a soft one: if it stops, events run late rather than the site going down. Monitor it, for example by alerting when wp cron event list --fields=hook,next_run_relative shows events overdue by more than a few minutes. Long jobs, such as a full catalogue import with wp lumen import, belong in their own scheduled command or a queue, not in a cron event that blocks the loop.

Standard WordPress opens one connection to one database server, which remains the scaling limit and the last single point of failure once the web tier is redundant. The usual steps, in order: a dedicated database server sized for the working set; a standby with automatic failover, which WordPress sees as one DB_HOST; and read replicas only when reads, not writes, overload the primary. Standard $wpdb cannot use replicas, so that step needs a db.php drop-in such as HyperDB or its maintained fork LudicrousDB (third-party ecosystem software). Replication lag is the main risk: the request after a save may read a replica that has not caught up. Keep replicas close to the primary, monitor lag and run reports and backups against a replica.

On AWS the managed service does the standby and the failover. The instance, parameter group, TLS from wp-config.php, connection math against PHP-FPM, RDS Proxy, the LudicrousDB installation and db-config.php listing, and a failover test are in Managed Database: RDS and Aurora.

Caching does more for a cluster than any other measure; the details are in Performance and Caching. Two rules are specific to clusters:

OPcache stays per node. With opcache.validate_timestamps=0, reload PHP-FPM or Apache on each node as part of the deployment.

In a cluster, updates reach every node through a deployment, and database upgrades run exactly once:

Old and new code briefly share one database, so a plugin update that changes the schema needs a maintenance window. On Kubernetes this is a rolling Deployment with readiness probes (see Kubernetes and Kubernetes: Autoscaling).

Measure capacity before a spike. A realistic test mixes cached anonymous page views with uncached work: search, logged-in browsing, comments, REST calls and, in a shop, cart actions. It yields three numbers: the uncached requests per second one node sustains (which sizes the web tier), the database load at that rate (which shows when replicas are needed), and the edge cache hit ratio. Test staging, or production by agreement with the host, from outside the cluster, and watch PHP-FPM’s queue, database connections and slow queries, and the object cache hit rate. Apache JMeter is documented in JMeter, including logged-in sessions and cookies and finding bottlenecks.

Lumen Press has predictable spikes (a prize announcement) and unpredictable ones (a viral review):

Older books, including Pro WordPress, discuss load balancing, replication, Varnish and Redis tiers and load testing. The general structure still holds, but several details have changed: