Optimizează strat cu strat — fiecare strat absoarbe sarcina înainte să ajungă la cel următor. Scopul este să servi cele mai multe cereri din cache și să ții PHP și baza de date ocupate cât mai puțin posibil.
Dimensionează pool-ul în funcție de RAM-ul disponibil și activează pentru ca PHP să fie compilat o dată, nu la fiecare cerere:
; 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)
Dacă max_children este prea mare, apare swap și crash; prea mic și cererile se pun în coadă (502 sub sarcină).
Această stratificare înseamnă că o cerere pentru pagina de start poate reveni de la edge sau din page cache fără să atingă deloc PHP sau DB.
Activează slow query log pentru a găsi problematici, adaugă indecși pentru interogări personalizate și auditează opțiuni autoloaded (wp_options cu autoload = yes se încarcă la fiecare cerere — datele autoload-ate umflate încetinesc totul). În cele din urmă, reduce plugin bloat: fiecare plugin adaugă interogări și muncă PHP, deci elimină cele nefolosite.
O cerere WordPress este în mod implicit grea în PHP și DB, deci se prăbușește sub trafic fără optimizare. Caching stratificat (OPcache → object cache → page cache → CDN) plus PHP-FPM dimensionat corect și o bază de date ușoară permite unui singur server să gestioneze ordine de mărime mai mult trafic — și să rămână activ în perioada de vârf.