Оптимізація PHP-сервера у 2026: PHP-FPM, OPcache, JIT та профілювання

Оптимізація PHP-сервера у 2026: PHP-FPM, OPcache, JIT та профілювання

PHP запустився у 1995 році як набір CGI-скриптів на Perl для відстеження відвідувачів сторінки. Через тридцять років він обслуговує близько 76% усього вебу (W3Techs, 2026) — від однієї людини, яка веде блог на WordPress, до Slack, Wikipedia і Etsy. Жодна інша мова не пройшла подібний шлях з настільки збереженою сумісністю: код, написаний у 2010-му, у переважній більшості випадків запуститься на PHP 8.4 без правок.

Те, що змінилось драматично — це спосіб запуску PHP на сервері. У 2010-му стандартом був mod_php в Apache: один процес Apache = один інтерпретатор PHP, повільно, споживливо до RAM, але просто. У 2026-му стандарт — PHP-FPM з окремим пулом воркерів, OPcache з прекомпільованим байткодом у пам'яті, JIT-компілятор, що генерує машинні інструкції для гарячих ділянок коду. Усе це разом дає продуктивність у 5-10 разів вищу за mod_php, але вимагає налаштування.

Проблема в тому, що apt пакети ставлять PHP з консервативними значеннями за замовчуванням — такими, щоб запустилось і на VPS з 512 МБ RAM, і на сервері з 64 ГБ. У результаті 90% серверів у Інтернеті працюють із конфігами, які ніяк не відповідають їхньому залізу. Це стаття про те, як виправити цю ситуацію — без академічної теорії, з конкретними числами і реальними прикладами для PHP 8.4 на Ubuntu 24.04 LTS.

Перший крок: знайти, що саме треба правити

Перед будь-якою оптимізацією треба точно знати, які саме файли конфігурації PHP читає на вашому сервері. На Ubuntu їх може бути кілька версій паралельно (PHP 8.1, 8.2, 8.3, 8.4 — все ставиться поряд), і часто-густо ваші зміни летять не туди, куди треба.

Команди, які дають точну відповідь

php -r 'echo php_ini_loaded_file() . PHP_EOL;'
# Виводить шлях до основного php.ini для CLI

php-fpm8.4 -i | grep "Loaded Configuration"
# Шлях до php.ini для FPM (часто це /etc/php/8.4/fpm/php.ini)

php -r 'echo phpversion() . PHP_EOL;'
# Версія PHP, з якою працює CLI

systemctl status php8.4-fpm
# Чи запущений FPM-сервіс і який саме

Структура каталогів PHP на Ubuntu

Якщо у вас інша версія PHP — підставте її номер замість 8.4. На старіших Ubuntu (18.04, 20.04) шляхи можуть починатися з /etc/php5 або /etc/php/7.x.

PHP-FPM Pool: ключ до тримання навантаження

FPM-пул — це те, скільки одночасних PHP-процесів сервер може обслуговувати. Якщо налаштовано неправильно, сайт буде або «падати» від нестачі воркерів, або «вбивати» сервер через нестачу RAM. Це найважливіший конфіг для перформансу, і саме тут роблять найбільше помилок.

Три режими роботи: dynamic / static / ondemand

Як розрахувати pm.max_children

Це число, яке найбільше впливає на стабільність. Формула:

pm.max_children = (Total RAM − RAM зайнята системою) / Середня RAM на один PHP-процес

На практиці один PHP-процес з WordPress і середнім набором плагінів їсть 50-80 МБ RAM під час обробки запиту. Для Laravel-додатків — 80-120 МБ. Magento 2 — 200-300 МБ. Заміряти точно можна командою:

ps -ylC php-fpm8.4 --sort:rss | awk '{sum+=$8; count++} END {print "Average:", sum/count/1024, "MB"}'

Приклад розрахунку для типових серверів

Оптимальний конфіг пулу для dynamic-режиму

Файл /etc/php/8.4/fpm/pool.d/www.conf:

; Базові налаштування пулу
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

; Slow log — записує запити повільніші за 5 секунд
slowlog = /var/log/php8.4-fpm-slow.log
request_slowlog_timeout = 5s

; Status page для моніторингу — дивіться з 127.0.0.1
pm.status_path = /fpm-status
ping.path = /fpm-ping

Slow log — недооцінений інструмент

Налаштування request_slowlog_timeout змушує FPM записувати у лог трасу будь-якого запиту, який виконується довше зазначеного часу. Це дозволяє знаходити «вузькі місця» без встановлення складних профайлерів. Приклад того, що з'являється у slow log:

[03-Jun-2026 14:23:15] [pool www] pid 12453
script_filename = /var/www/site/wp-cron.php
[0x00007f5e2c4a8e30] curl_exec() /var/www/site/wp-includes/class-wp-http-curl.php:155
[0x00007f5e2c4a8e30] request() /var/www/site/wp-includes/class-wp-http.php:413

Тут одразу видно: запит висить на curl_exec() у wp-cron — найімовірніше, плагін намагається достукатися до зовнішнього API, який не відповідає. Без slow log ця проблема залишилася б невидимою.

OPcache: каже одне число, що змінює все

OPcache — це вбудований у PHP байткод-кеш. Без нього PHP при кожному запиті заново читає всі .php-файли з диску, парсить їх у байткод і тільки потім виконує. З увімкненим OPcache байткод зберігається в RAM, і повторні виклики того ж файлу читають уже скомпільовану версію.

Це дає прискорення у 3-5 разів для будь-якого PHP-додатку без зміни жодного рядка коду. Це не теоретична цифра — це реальна різниця, яку видно на будь-якому профайлері.

Перевірити, чи OPcache увімкнений

php -r 'echo opcache_get_status() ? "OPcache: ON" : "OPcache: OFF"; echo PHP_EOL;'

Якщо OFF — увімкніть. На Ubuntu пакет називається php8.4-opcache (зазвичай уже встановлений за замовчуванням, але вимкнений у конфізі).

Робочий конфіг OPcache для продакшну

Файл /etc/php/8.4/mods-available/opcache.ini:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit=tracing
opcache.jit_buffer_size=128M

Що означає кожен параметр

Важливий нюанс: validate_timestamps=0 для продакшну

Це найбільш суперечливий параметр. Якщо встановити validate_timestamps=0, PHP перестає перевіряти зміни файлів — і будь-яке оновлення коду треба супроводжувати ручним очищенням OPcache (php8.4-fpm reload або opcache_reset()). Натомість продуктивність зростає ще на 5-10%, бо нема системних викликів stat() при кожному запиті.

Чи варто? Залежить від процесу деплою. Якщо у вас CI/CD pipeline з автоматичним перезавантаженням FPM після релізу — точно так. Якщо ви оновлюєте сайт через FTP вручну і забуваєте перезавантажити сервіс — краще залишити validate_timestamps=1.

JIT compiler: коли вмикати, а коли — НІ

JIT (Just-In-Time compiler) з'явився у PHP 8.0 і дозволяє компілювати «гарячий» код у машинні інструкції процесора, обходячи інтерпретатор. Звучить як магія прискорення, але на практиці все цікавіше.

Де JIT реально допомагає

• CPU-bound обчислення: рендеринг зображень, криптографія, парсинг великих структур даних, математичні алгоритми. Тут JIT може дати прискорення у 1.5-3 рази.
• CLI-скрипти: довгі обробки даних, фонові обчислення, наукові розрахунки.

Де JIT не допомагає, а інколи шкодить

• Типові веб-додатки (WordPress, Drupal, Laravel): вони I/O-bound (більшість часу проводять у запитах до БД, читанні файлів, очікуванні відповідей API). Прискорення від JIT — у межах 1-3%, що часто непомітно на тлі звичайної дисперсії.
• Сайти з помилками сегментації: JIT у деяких випадках конфліктує зі сторонніми розширеннями. Якщо у логах з'явилися крахи воркерів після увімкнення — це перша гіпотеза.

Налаштування JIT

JIT керується через два параметри в opcache.ini:

opcache.jit=tracing
opcache.jit_buffer_size=128M

Рекомендація: увімкніть tracing, заміряйте продуктивність до і після, тримайте увімкненим тільки якщо різниця помітна. На сайті з типовим CMS-навантаженням JIT може просто з'їсти 128 МБ RAM і нічого не дати в обмін.

Як заміряти ефект від JIT

Найпростіший спосіб — два інструменти разом: Apache Bench для навантажувального тесту і моніторинг через top:

# Тест без JIT (попередньо вимкніть JIT і перезавантажте FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Тест з JIT (увімкніть, перезавантажте FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Порівняйте "Requests per second" і "Time per request"

Якщо різниця менше 5% — JIT для вашого випадку економічно безглуздий, можна вимкнути і повернути 128 МБ RAM у систему.

Realpath cache: маленький параметр, який рятує SSD

Параметр, про який рідко говорять, але який має непропорційно великий ефект на сайтах з великою кількістю файлів (WordPress з 50+ плагінами, Magento, великі Laravel-проєкти).

Кожного разу, коли PHP підключає файл через require або include, він резолвить шлях через серію stat() системних викликів. Для відносного шляху типу ../vendor/symfony/finder/Finder.php це означає декілька десятків викликів до файлової системи. Realpath cache зберігає вже розв'язані шляхи в пам'яті.

Налаштування realpath_cache

У php.ini:

realpath_cache_size = 4096K
realpath_cache_ttl = 600

За замовчуванням стоїть 256K — цього вистачає на ~150 кешованих шляхів. Для WordPress з пристойним набором плагінів треба мінімум 2-4 MB. Перевірити поточне використання:

php -r 'echo realpath_cache_size() / 1024 . " KB used\n";'
# Скільки байтів реально займає кеш на даний момент

php -r 'print_r(realpath_cache_get());'
# Повний список усіх кешованих шляхів (корисно для діагностики)

Якщо число з першої команди близьке до значення realpath_cache_size у php.ini — кеш переповнюється, треба збільшувати ліміт.

Профілювання: знайти, що насправді гальмує

До цього моменту ми тюнили «вгадуючи»: збільшили OPcache, збільшили pool, увімкнули JIT. Але справжня оптимізація починається тоді, коли ви бачите, де саме код проводить час. Без профілювання ви тюните не свій сайт, а абстрактного «середнього сайт».

Інструменти за зростанням складності

З чого почати: OPcache GUI

OPcache GUI — це маленький .php-скрипт, який показує детальну статистику використання кешу. Встановлюється за хвилину:

cd /var/www/site/
wget https://raw.githubusercontent.com/amnuts/opcache-gui/master/index.php -O opcache-status.php

Після цього відкрийте у браузері https://yoursite.com/opcache-status.php — побачите memory usage, hit ratio, кількість кешованих файлів і список того, що в кеші. Якщо hit ratio менше 99% — це сигнал, що memory_consumption замалий.

Xdebug profiler — тонке профілювання

Xdebug — це найвідоміший дебагер і профайлер для PHP. Для профілювання його використовують у режимі profile:

; У /etc/php/8.4/mods-available/xdebug.ini
xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug
xdebug.start_with_request = trigger

Після цього додайте параметр ?XDEBUG_TRIGGER=1 до URL — і Xdebug запише профіль виклику у каталог /tmp/xdebug. Відкрийте отриманий cachegrind.out файл у KCachegrind або QCachegrind — побачите ієрархію викликів з часом, відсотками і кількістю викликів.

PHP-специфічна безпека: те, що не покривають інші статті

Загальна безпека сервера (HTTPS, fail2ban, security headers) детально розкрита у нашій статті про захист сайту від хакерів. Тут — суто PHP-рівень: параметри, які можна виставити в php.ini і які закривають специфічні для PHP вектори атаки.

expose_php = Off

За замовчуванням PHP додає заголовок X-Powered-By: PHP/8.4.X до кожної відповіді. Це безкоштовна інформація для атакуючого: він точно знає вашу версію і може шукати CVE під неї. Вимкнути просто:

expose_php = Off

Перевірити після перезапуску FPM:

curl -I https://yoursite.com/ | grep -i powered
# Якщо нічого не виводить — заголовок прибраний

disable_functions: що дійсно варто вимикати

Це список PHP-функцій, які ніколи не виконуватимуться. Якщо плагін або вразливість намагається через них вирватися на рівень shell — PHP просто видасть помилку. Розумний мінімум для більшості сайтів:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source,phpinfo

open_basedir: ізоляція PHP від файлової системи

Цей параметр обмежує, до яких каталогів PHP-скрипт може звертатися. Навіть якщо зловмисник завантажив shell у /uploads, він не зможе через нього прочитати /etc/passwd або /var/log:

open_basedir = /var/www/yoursite/:/tmp/

Усе поза цими каталогами стає недоступним для функцій типу file_get_contents, fopen, include. Це один з найсильніших захистів на рівні PHP, але часто пропускається.

allow_url_fopen = Off (де можливо)

За замовчуванням PHP дозволяє відкривати URL так само як файли: file_get_contents('https://...'). Зловмисник може цим скористатися для:

• SSRF (Server-Side Request Forgery) — змусити сервер ходити по внутрішніх ресурсах
• Remote File Inclusion — підключити шкідливий PHP-код з зовнішнього сервера

Якщо ваш код не звертається до зовнішніх URL через file_get_contents (а замість цього використовує cURL або Guzzle, як прийнято у сучасних додатках) — вимкніть:

allow_url_fopen = Off
allow_url_include = Off

allow_url_include треба вимикати завжди — це окремий вектор для Remote File Inclusion і у 99% випадків нікому не потрібен.

session.cookie_httponly, session.cookie_secure

Налаштування PHP-сесій. Без них JavaScript на сторінці може прочитати session cookie (наприклад, через XSS-вразливість), або session cookie буде передаватися по HTTP в обхід HTTPS:

session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"
session.use_strict_mode = 1

Топ помилок конфігурації, які я бачу на чужих серверах

1. memory_limit = -1 «на всякий випадок». Це означає «без обмежень». Один зациклений скрипт може з'їсти всю RAM сервера. Має стояти конкретне число: 256M, 512M, 1024M.
2. max_execution_time = 0. Те саме що вище — скрипт без таймауту може висіти годинами, тримаючи воркер FPM. 60-90 секунд — нормальний діапазон для більшості сайтів.
3. display_errors = On у продакшні. Помилки виводяться користувачам у браузер разом зі шляхами до файлів, версіями бібліотек і інколи фрагментами SQL. Видавайте їх тільки на dev-сервері. У продакшн — display_errors = Off, log_errors = On.
4. pm.max_children обраний наосліп. Або поставили 5 і сайт «падає» при першому ж сплеску трафіку, або поставили 200 і сервер захлинається. Розрахуйте формулою з секції про FPM.
5. OPcache з memory_consumption=64. Стандартне значення з більшості туторіалів. Для будь-якого реального сайту з CMS це замало, кеш постійно переповнюється і скидається. Мінімум 128, реалістично 256-512.
6. opcache.validate_timestamps=0 без CI/CD. Після деплою сайт показує стару версію коду, а адміни в розпачі шукають баги. Або ставте 1, або налаштовуйте автоматичний reload FPM після релізу.
7. JIT з buffer_size=512M, бо «більше = краще». На сайті з CMS це з'їдає півгігабайта RAM ні за що. JIT використовує тільки те, що йому реально треба — починайте з 64-128M.
8. info.php / phpinfo.php залишився у production. Тимчасовий файл, який створили для перевірки, але забули видалити. Атакуючий бачить версію PHP, всі завантажені модулі, шляхи, переменні середовища. Видаляйте відразу після перевірки — детальніше про небезпеку розкриття версій ПЗ і способи приховати їх ми писали у матеріалі про перевірку версії Apache.

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