Optimera lager för lager — varje lager absorberar belastning innan den når nästa. Målet är att serva de flesta förfrågningar från en cache och hålla PHP och databasen så opåverkatade som möjligt.
Dimensionera -poolen efter din RAM, och aktivera så PHP kompileras en gång, inte vid varje förfrågan:
; 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)
Om max_children är för högt får du swap och krasch; för lågt och förfrågningar köar (502:or under belastning).
Denna lagring innebär att en startsidaträff kan returneras från kanten eller sidcachen utan att röra PHP eller databasen överhuvudtaget.
Aktivera långsam frågelog för att hitta överträdare, lägg till index för anpassade frågor, och granska autoloaded options (wp_options med autoload = yes laddar vid varje förfrågan — överlastad autoload-data saktar allt ned). Slutligen, minska instickskomplex: varje instick lägger till frågor och PHP-arbete, så ta bort oanvända.
En WordPress-förfrågan är PHP- och databasintensiv som standard, så den kraschar under trafik utan optimering. Lagerspridd caching (OPcache → object cache → sidcache → CDN) plus korrekt dimensionerad PHP-FPM och en smal databas låter en enda server hantera storleksordningar mer trafik — och håller den upp under toppar.