Оптимизируйте слой за слоем — каждый слой поглощает нагрузку перед тем, как она достигнет следующего. Цель — обслуживать большинство запросов из кэша и держать PHP и базу данных в минимальной нагрузке.
Размер пула должен соответствовать вашей ОЗУ, и включите , чтобы PHP компилировался один раз, а не при каждом запросе:
; 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)
Если max_children слишком высоко, вы начнёте использовать swap и упадёте; слишком низко — запросы встанут в очередь (502 ошибки при нагрузке).
Эта многоуровневость означает, что запрос к домашней странице может вернуться с края или из page cache без обращения к PHP или БД.
Включите slow query log для поиска проблемных запросов, добавьте индексы для пользовательских запросов и проверьте автозагружаемые опции (wp_options с autoload = yes загружаются при каждом запросе — раздутые данные автозагрузки замедляют всё). Наконец, уменьшите bloat плагинов: каждый плагин добавляет запросы и нагрузку на PHP, поэтому удалите неиспользуемые.
WildPress запрос по умолчанию тяжелый для PHP и БД, поэтому он падает при трафике без оптимизации. Многоуровневое кэширование (OPcache → object cache → page cache → CDN) плюс правильный размер PHP-FPM и стройная база данных позволяют одному серверу обрабатывать на порядки больше трафика — и оставаться стабильным во время пиков нагрузки.