Optimize layer by layer — each layer absorbs load before it reaches the next. The goal is to serve most requests from a cache and keep PHP and the database doing as little work as possible.
Size the pool to your RAM, and enable so PHP is compiled once, not on every request:
; php-fpm pool: cap workers so you don't exhaust RAM
; pm.max_children = (available RAM for PHP) / (avg process size, ~50MB)
pm = dynamic
pm.max_children = 40 ; hard ceiling on concurrent PHP workers
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; recycle workers to avoid memory leaks
; OPcache: cache compiled bytecode in memory
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; skip file-stat checks in prod (flush on deploy)
If max_children is too high you swap and crash; too low and requests queue (502s under load).
This layering means a homepage hit can return from the edge or page cache without touching PHP or the DB at all.
Enable the slow query log to find offenders, add indexes for custom queries, and audit autoloaded options (wp_options with autoload = yes loads on every request — bloated autoload data slows everything). Finally, reduce plugin bloat: each plugin adds queries and PHP work, so remove unused ones.
A WordPress request is PHP- and DB-heavy by default, so it falls over under traffic without tuning. Layered caching (OPcache → object cache → page cache → CDN) plus right-sized PHP-FPM and a lean database lets a single server handle orders of magnitude more traffic — and keeps it up during spikes.