Stem laag voor laag af — elke laag absorbeert belasting voordat deze de volgende laag bereikt. Het doel is om de meeste verzoeken vanuit een cache te serveren en PHP en de database zo weinig mogelijk werk te laten doen.
Stel de pool in op je RAM-grootte, en schakel in zodat PHP eenmaal wordt gecompileerd in plaats van bij elk verzoek:
; 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)
Als max_children te hoog is, krijg je swaps en crashes; te laag en verzoeken rijen zich op (502s onder belasting).
Deze gelaagdheid betekent dat een homepage-hit kan terugkeren van de rand of page cache zonder PHP of de DB helemaal aan te raken.
Schakel het slow query log in om overtreders te vinden, voeg indexes toe voor aangepaste query's, en audit autoloaded options (wp_options met autoload = yes laden bij elk verzoek — opgeblazen autoload-gegevens vertragen alles). Tenslotte, verminder plugin-overhead: elke plugin voegt query's en PHP-werk toe, dus verwijder ongebruikte plugins.
Een WordPress-verzoek is standaard PHP- en DB-zwaar, dus het crasht onder verkeer zonder afstemming. Gelaagde caching (OPcache → object cache → page cache → CDN) plus correct geformatteerde PHP-FPM en een slank database laat een enkele server orders of magnitude meer verkeer aan — en houdt het draaiende tijdens pieken.