Optimalizálj rétegről rétegre — minden réteg felszívja a terhelést, mielőtt az átmenne a következőre. A cél, hogy a legtöbb kérést cache-ből szolgáljuk fel, és a PHP és az adatbázis a lehető legkevesebb munkát végezze.
Méretezd a készletet a RAM-odhoz, és engedélyezd az -t, hogy a PHP egyszer legyen fordítva, ne minden kérésnél:
; 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)
Ha a max_children túl magas, akkor cserélj és összeomlasz; túl alacsony és a kérések sorokba válnak (502-esek nagy terhelés alatt).
Ez a rétegzett megközelítés azt jelenti, hogy egy kezdőlap-találat a peremről vagy az oldal gyorsítótárából térhet vissza anélkül, hogy egyáltalán hozzáérnél a PHP-hez vagy az adatbázishoz.
Engedélyezd a slow query log-ot a problémás lekérdezések megtalálásához, adj hozzá indexes-t az egyéni lekérdezésekhez, és auditáld az autoloaded options-t (wp_options a autoload = yes értékkel minden kérésnél betöltődik — a felduzzadt autoload-adatok lelassítják az egészet). Végül csökkentsd a bővítmények terhelését: minden bővítmény lekérdezéseket és PHP-munkát ad hozzá, ezért távolítsd el a nem használtakat.
Az WordPress-kérés alapértelmezésben PHP- és adatbázis-igényes, ezért összeomlásba kerül nagy forgalom alatt hangolás nélkül. A rétegzett gyorsítótárazás (OPcache → objektumcache → oldal gyorsítótára → CDN) plus a megfelelő méretű PHP-FPM és egy karcsú adatbázis lehetővé teszi, hogy egyetlen szerver nagyságrendekkel több forgalmat kezeljen — és az csúcsok alatt is működjön.