Як оптимізувати PHP для WordPress

Коротка відповідь: Запускайте PHP 8.3 з увімкненим OPcache, розмірте FPM-пул від вашої RAM (pm.max_children ≈ доступна RAM ÷ ~60–80 MB на воркер), поставте memory_limit = 256M і підніміть ліміти завантаження до практичних значень (64M). Розмір PHP-FPM — це різниця між стабільним сайтом і 502-ми під навантаженням.

Огляд

Кожен незакешований запит WordPress — це запит PHP, тож конфігурація PHP прямо задає стелю вашої пропускної здатності. Домінують два важелі: OPcache (прибирає вартість перекомпіляції — майже безкоштовна швидкість) і менеджер процесів FPM (скільки запитів ви обслужите паралельно до появи черги).

Що потрібно мати

• Знання апетиту воркера: підженіть трафік і перевірте

  ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; n++} END {print sum/n/1024 " MB avg"}'

• Знання вільної RAM після MariaDB/Redis/вебсервера: free -h.

Покрокова інструкція

1. Відредагуйте пул (/etc/php/8.3/fpm/pool.d/www.conf) — приклад для ~2 GB вільної RAM і воркерів по ~70 MB:

   pm = dynamic
   pm.max_children = 25
   pm.start_servers = 5
   pm.min_spare_servers = 3
   pm.max_spare_servers = 8
   pm.max_requests = 500

2. Підкрутіть /etc/php/8.3/fpm/php.ini:

   memory_limit = 256M
   upload_max_filesize = 64M
   post_max_size = 64M
   max_execution_time = 120

3. Перевірте OPcache і дайте йому простір (php.ini, зазвичай уже увімкнено):

   opcache.enable=1
   opcache.memory_consumption=192
   opcache.max_accelerated_files=20000
   opcache.validate_timestamps=1

4. Застосуйте й перевірте: sudo systemctl reload php8.3-fpm, потім стежте за попередженнями «server reached pm.max_children» у /var/log/php8.3-fpm.log — це повідомлення означає, що пул замалий (або запити занадто повільні).

Типові проблеми

• 502/504 під навантаженням: пул вичерпано — піднімайте pm.max_children лише якщо дозволяє RAM, інакше здешевлюйте запити (кешування) або додавайте RAM.
• max_children від RAM, якої немає: воркери × апетит мають вміщатись у вільну RAM, інакше OOM killer першою вб'є MariaDB.
• Плутанина з memory_limit: це ліміт на запит, а не сумарний — 256M не означає, що кожен запит їсть 256 MB.

Коли звертатися в підтримку

Якщо натюнений FPM + кешування все одно впираються в стелю — навантаження переросло план: відкрийте тикет, щоб обговорити апгрейд на більше vCPU/RAM (Power VPS для CPU-важких динамічних сайтів).

Часті запитання

Як порахувати pm.max_children для PHP-FPM?

Поділіть RAM, яку можете віддати PHP, на середній апетит одного воркера (для WordPress зазвичай 60–80 MB): 2 GB вільних / 70 MB — це приблизно 25–28 воркерів, і залиште запас для бази даних.

Чи справді оновлення версії PHP пришвидшує WordPress?

Так — PHP 8.x у бенчмарках на WordPress помітно швидший за 7.4 і отримує security-патчі; протестуйте плагіни на staging, а потім оновлюйтеся через PPA ondrej або свою панель.

Що робить pm.max_requests?

Він перезапускає кожен FPM-воркер після N запитів (наприклад, 500), що маскує повільні витоки пам'яті у плагінах і не дає довгоживучим пулам розпухати днями.

Схожі статті

• Як пришвидшити WordPress на VPS
• Як оптимізувати MariaDB для WordPress
• Як полагодити помилку 500 у WordPress
• Як встановити PHP

Готові почати? Замовити WordPress VPS у Cloud2Y →