The enterprise WordPress cluster I actually deploy

WordPress is not slow. The stack we wrap around it is slow: uncached PHP, a single database host, and NFS-mounted uploads that nobody measured.

This is the architecture I deploy for enterprise clients and have kept running for years.

The stack at a glance

Three keys that decide everything

One — shared storage must be fast. Put wp-content on NFS with 20ms latency and image uploads will take down the cluster. Use distributed block storage, or object storage with CDN offload.

Two — object cache lives outside the pod. Redis needs persistence and replication, not a container that disappears on deploy.

Three — health checks must test PHP, not just TCP. If the check only pings port 8443, the balancer will happily route traffic to a node whose PHP is dead.

# LiteSpeed ADC upstream health check
upstream wordpress_backend {
  least_conn;
  server 10.10.0.11:443 max_fails=3 fail_timeout=10s;
  server 10.10.0.12:443 max_fails=3 fail_timeout=10s;
  server 10.10.0.13:443 max_fails=3 fail_timeout=10s;
}

PHP values worth tuning

memory_limit = 512M
max_execution_time = 120
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
realpath_cache_size = 4096k

validate_timestamps = 0 is a real trade-off: measurably faster, but PHP-FPM must reload on every deploy. Wire that into the pipeline.

Measured outcome

On a client e-commerce site serving Thailand and ASEAN:

• TTFB from 1.4s to 180ms with a 94% cache hit rate
• 6× the concurrent users on the same number of machines
• Plugin updates moved from "announce maintenance" to zero-downtime rolling releases

What people forget

• Update core one node at a time and run the checkout flow after each.
• Set Redis maxmemory-policy allkeys-lru; noeviction turns a full cache into failed writes.
• Keep immutable backups — ransomware hunts mounted backups first.
• Test failover quarterly. Untested failover is a rumour.