Optymalizuj warstwę po warstwie — każda warstwa przejmuje obciążenie, zanim dotrze do następnej. Celem jest serwowanie większości żądań z cache'a i utrzymanie PHP oraz bazy danych na jak niskim poziomie pracy.
Wymiar pulę w stosunku do pamięci RAM i włącz , aby PHP został skompilowany raz, a nie przy każdym żądaniu:
; 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)
Jeśli max_children jest zbyt wysokie, system swap'uje i pada; jeśli zbyt niskie, żądania się kolejkują (502 pod obciążeniem).
To warstwowe podejście oznacza, że trafienie na stronę główną może być zwrócone z krawędzi lub cache'a strony bez dotykania PHP lub bazy danych.
Włącz dziennik wolnych zapytań, aby znaleźć problematyczne zapytania, dodaj indeksy dla zapytań niestandardowych i przeanalizuj opcje autoload'owane (wp_options z autoload = yes ładuje się na każdym żądaniu — puchnące dane autoload'u spowalniają wszystko). Na koniec zmniejsz wzdęcia wtyczek: każda wtyczka dodaje zapytania i pracę PHP, dlatego usuń nieużywane.
Zapytanie WordPress'a jest domyślnie ciężkie dla PHP i bazy danych, dlatego pada pod obciążeniem bez optymalizacji. Warstwowe cache'owanie (OPcache → cache obiektu → cache strony → CDN) plus odpowiednio wymiarowana PHP-FPM i szczupła baza danych pozwalają pojedynczemu serwerowi obsługiwać wielokrotnie większy ruch — i utrzymywać go podczas skoków obciążenia.