Optimalizace PHP serveru v roce 2026: PHP-FPM, OPcache, JIT a profilování

Optimalizace PHP serveru v roce 2026: PHP-FPM, OPcache, JIT a profilování

PHP vzniklo v roce 1995 jako sada CGI skriptů v Perlu pro sledování návštěvníků stránky. O třicet let později obsluhuje zhruba 76 % celého webu (W3Techs, 2026) — od jednotlivce, který si vede WordPress blog, až po Slack, Wikipedii a Etsy. Žádný jiný jazyk neušel takovou cestu se zachovanou kompatibilitou: kód napsaný v roce 2010 se v drtivé většině případů spustí na PHP 8.4 beze změn.

Co se dramaticky změnilo, je způsob, jak PHP běží na serveru. V roce 2010 byl standardem mod_php v Apachi: jeden Apache proces = jeden PHP interpret, pomalé, paměťově náročné, ale jednoduché. V roce 2026 je standardem PHP-FPM s vlastním poolem workerů, OPcache s předkompilovaným bytecodem v paměti a JIT kompilátor, který generuje strojové instrukce pro horké úseky kódu. Dohromady to dává 5–10× vyšší výkon než mod_php, ale vyžaduje to nastavení.

Problém je v tom, že apt balíčky instalují PHP s konzervativními výchozími hodnotami — takovými, aby se to spustilo i na VPS s 512 MB RAM i na serveru s 64 GB. Výsledkem je, že 90 % serverů na internetu jede s konfigurací, která vůbec neodpovídá jejich železu. Tento článek je o tom, jak to napravit — bez akademické teorie, s konkrétními čísly a reálnými příklady pro PHP 8.4 na Ubuntu 24.04 LTS.

První krok: najít, co je potřeba upravit

Před jakoukoli optimalizací je třeba přesně vědět, které konfigurační soubory PHP váš server čte. Na Ubuntu může vedle sebe běžet více verzí (PHP 8.1, 8.2, 8.3, 8.4 se instalují paralelně), a vaše změny častokrát putují někam, kam nemají.

Příkazy, které dají jasnou odpověď

php -r 'echo php_ini_loaded_file() . PHP_EOL;'
# Vypíše cestu k hlavnímu php.ini pro CLI

php-fpm8.4 -i | grep "Loaded Configuration"
# Cesta k php.ini pro FPM (obvykle /etc/php/8.4/fpm/php.ini)

php -r 'echo phpversion() . PHP_EOL;'
# Verze PHP, se kterou pracuje CLI

systemctl status php8.4-fpm
# Zda běží FPM služba a v jaké verzi

Struktura PHP adresářů na Ubuntu

Pokud máte jinou verzi PHP, dosaďte její číslo místo 8.4. Na starších Ubuntu (18.04, 20.04) mohou cesty začínat /etc/php5 nebo /etc/php/7.x.

PHP-FPM Pool: klíč k zvládnutí zátěže

FPM pool určuje, kolik souběžných PHP procesů server obslouží. Při špatném nastavení web buď „padá" kvůli nedostatku workerů, nebo „zabíjí" server přes nedostatek RAM. Je to nejdůležitější konfigurace pro výkon a právě tady se dělá nejvíc chyb.

Tři režimy: dynamic / static / ondemand

Jak vypočítat pm.max_children

Je to číslo, které má největší vliv na stabilitu. Vzorec:

pm.max_children = (Total RAM − RAM zabraná systémem) / Průměrná RAM na jeden PHP proces

V praxi jeden PHP proces s WordPressem a běžnou sadou pluginů sní 50–80 MB RAM během zpracování požadavku. Pro Laravel aplikace — 80–120 MB. Magento 2 — 200–300 MB. Přesně změřit lze příkazem:

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

Příklad výpočtu pro typické servery

Optimální konfigurace poolu pro režim dynamic

Soubor /etc/php/8.4/fpm/pool.d/www.conf:

; Základní nastavení poolu
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 — zaznamenává požadavky pomalejší než 5 sekund
slowlog = /var/log/php8.4-fpm-slow.log
request_slowlog_timeout = 5s

; Status stránka pro monitoring — přístup z 127.0.0.1
pm.status_path = /fpm-status
ping.path = /fpm-ping

Slow log — nedoceněný nástroj

Nastavení request_slowlog_timeout nutí FPM zapsat do logu trasování každého požadavku, který trvá déle než zadaný čas. Umožňuje to najít úzká místa bez instalace složitých profilerů. Příklad zápisu ve slow logu:

[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

Hned je vidět: požadavek visí na curl_exec() ve wp-cron — nejspíš se plugin snaží dovolat na externí API, které neodpovídá. Bez slow logu by tento problém zůstal neviditelný.

OPcache: jedno číslo, které mění všechno

OPcache je vestavěný bytecode cache v PHP. Bez něj PHP při každém požadavku znovu čte všechny .php soubory z disku, parsuje je do bytecodu a teprve potom spouští. Se zapnutým OPcache se bytecode ukládá do RAM a opakovaná volání téhož souboru čtou už zkompilovanou verzi.

To dává zrychlení 3–5× pro jakoukoli PHP aplikaci bez změny jediného řádku kódu. Není to teoretické číslo — je to reálný rozdíl viditelný na jakémkoli profileru.

Ověření, zda je OPcache zapnutý

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

Pokud OFF — zapněte. Na Ubuntu se balíček jmenuje php8.4-opcache (obvykle už nainstalovaný, ale v konfiguraci vypnutý).

Funkční konfigurace OPcache pro produkci

Soubor /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

Co znamená každý parametr

Důležitá nuance: validate_timestamps=0 pro produkci

Je to nejkontroverznější parametr. Pokud nastavíte validate_timestamps=0, PHP přestane kontrolovat změny souborů — a jakákoli aktualizace kódu musí být doprovázena ručním vyčištěním OPcache (php8.4-fpm reload nebo opcache_reset()). Výkon naproti tomu vzroste o dalších 5–10 %, protože odpadnou systémová volání stat() při každém požadavku.

Vyplatí se? Záleží na procesu nasazení. Pokud máte CI/CD pipeline s automatickým reloadem FPM po releasu — určitě ano. Pokud aktualizujete web ručně přes FTP a zapomínáte restartovat službu — raději nechte validate_timestamps=1.

JIT compiler: kdy zapnout a kdy NE

JIT (Just-In-Time compiler) se objevil v PHP 8.0 a umožňuje kompilovat „horký" kód do strojových instrukcí procesoru, čímž obchází interpret. Zní to jako kouzelná hůlka zrychlení, v praxi je to ale zajímavější.

Kde JIT skutečně pomáhá

• CPU-bound výpočty: renderování obrázků, kryptografie, parsování velkých datových struktur, matematické algoritmy. Tady může JIT dát 1,5–3× zrychlení.
• CLI skripty: dlouhé zpracování dat, výpočty na pozadí, vědecké úlohy.

Kde JIT nepomáhá a někdy škodí

• Typické webové aplikace (WordPress, Drupal, Laravel): jsou I/O-bound (většinu času tráví v dotazech do DB, čtení souborů, čekání na API odpovědi). Zrychlení od JIT je v rozsahu 1–3 %, často nepozorovatelné na pozadí běžné disperze.
• Weby se segfaulty: JIT v některých případech koliduje s rozšířeními třetích stran. Pokud se v logu po zapnutí objeví pády workerů — to je první hypotéza.

Konfigurace JIT

JIT se ovládá dvěma parametry v opcache.ini:

opcache.jit=tracing
opcache.jit_buffer_size=128M

Doporučení: zapněte tracing, změřte výkon před a po, nechte zapnuté jen pokud je rozdíl znatelný. Na webu s typickou CMS zátěží může JIT prostě sníst 128 MB RAM a nic za to nedat.

Jak změřit efekt JIT

Nejjednodušší způsob — dva nástroje dohromady: Apache Bench pro zátěžový test a monitoring přes top:

# Test bez JIT (nejdřív vypněte JIT a restartujte FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Test s JIT (zapněte, restartujte FPM)
ab -n 1000 -c 10 https://yoursite.com/

# Porovnejte "Requests per second" a "Time per request"

Pokud je rozdíl menší než 5 % — JIT je pro váš případ ekonomicky nesmyslný, můžete jej vypnout a vrátit 128 MB RAM systému.

Realpath cache: malý parametr, který zachrání váš SSD

Parametr, o kterém se mluví zřídka, ale který má neproporčně velký efekt na webech s velkým množstvím souborů (WordPress s 50+ pluginy, Magento, velké Laravel projekty).

Pokaždé, když PHP přes require nebo include připojuje soubor, řeší cestu sérií systémových volání stat(). U relativní cesty jako ../vendor/symfony/finder/Finder.php to znamená několik desítek volání do souborového systému. Realpath cache ukládá už vyřešené cesty v paměti.

Konfigurace realpath_cache

V php.ini:

realpath_cache_size = 4096K
realpath_cache_ttl = 600

Výchozí hodnota je 256K — to stačí na ~150 cachovaných cest. Pro WordPress se slušnou sadou pluginů je potřeba minimálně 2–4 MB. Aktuální využití zjistíte:

php -r 'echo realpath_cache_size() / 1024 . " KB used\n";'
# Kolik bajtů reálně cache zabírá v daný okamžik

php -r 'print_r(realpath_cache_get());'
# Úplný seznam všech cachovaných cest (užitečné pro diagnostiku)

Pokud je číslo z prvního příkazu blízké hodnotě realpath_cache_size v php.ini — cache přetéká, je třeba zvýšit limit.

Profilování: najít, co skutečně zpomaluje

Až dosud jsme ladili „odhadem": zvýšili OPcache, zvýšili pool, zapnuli JIT. Ale skutečná optimalizace začíná tehdy, když vidíte, kde přesně kód tráví čas. Bez profilování neladíte svůj web, ale abstraktní „průměrný web".

Nástroje seřazené podle složitosti

Kde začít: OPcache GUI

OPcache GUI je malý .php skript, který ukazuje detailní statistiku využití cache. Instalace za minutu:

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

Potom otevřete v prohlížeči https://yoursite.com/opcache-status.php — uvidíte memory usage, hit ratio, počet cachovaných souborů a seznam toho, co je v cache. Pokud je hit ratio nižší než 99 % — je to signál, že memory_consumption je moc malý.

Xdebug profiler — jemné profilování

Xdebug je nejznámější debugger a profiler pro PHP. Pro profilování se používá v režimu profile:

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

Pak přidejte parametr ?XDEBUG_TRIGGER=1 k URL — a Xdebug zapíše profil volání do /tmp/xdebug. Otevřete získaný soubor cachegrind.out v KCachegrind nebo QCachegrind — uvidíte hierarchii volání s časy, procenty a počty volání.

PHP-specifická bezpečnost: to, co ostatní články nepokrývají

Obecná bezpečnost serveru (HTTPS, fail2ban, security headers) je podrobně rozebrána v našem článku o ochraně webu před hackery. Zde — čistě PHP úroveň: parametry, které lze nastavit v php.ini a které zavírají PHP-specifické útočné vektory.

expose_php = Off

Ve výchozím nastavení PHP přidává do každé odpovědi hlavičku X-Powered-By: PHP/8.4.X. To je informace útočníkovi zdarma: ví přesně vaši verzi a může pod ni hledat CVE. Vypnutí je jednoduché:

expose_php = Off

Ověření po restartu FPM:

curl -I https://yoursite.com/ | grep -i powered
# Pokud nic nevypíše — hlavička je pryč

disable_functions: co skutečně stojí za vypnutí

Toto je seznam PHP funkcí, které se nikdy nespustí. Pokud se přes ně plugin nebo zranitelnost pokusí vyrazit na úroveň shellu — PHP prostě vypíše chybu. Rozumné minimum pro většinu webů:

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

open_basedir: izolace PHP od souborového systému

Tento parametr omezuje, do kterých adresářů má PHP skript přístup. I když útočník nahraje shell do /uploads, přes něj nepřečte /etc/passwd ani /var/log:

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

Vše mimo tyto adresáře se stává nedostupným pro funkce typu file_get_contents, fopen, include. Jedna z nejsilnějších ochran na úrovni PHP — a často se přeskakuje.

allow_url_fopen = Off (kde je to možné)

Ve výchozím nastavení PHP dovoluje otevírat URL stejně jako soubory: file_get_contents('https://...'). Útočník toho může využít pro:

• SSRF (Server-Side Request Forgery) — donutit server, aby chodil po interních zdrojích
• Remote File Inclusion — připojit škodlivý PHP kód z externího serveru

Pokud váš kód nepřistupuje k externím URL přes file_get_contents (a místo toho používá cURL nebo Guzzle, jak je v moderních aplikacích zvykem) — vypněte:

allow_url_fopen = Off
allow_url_include = Off

allow_url_include by měl být vypnutý vždy — je to samostatný vektor pro Remote File Inclusion a v 99 % případů jej nikdo nepotřebuje.

session.cookie_httponly, session.cookie_secure

Nastavení PHP sessionů. Bez nich může JavaScript na stránce přečíst session cookie (například přes XSS zranitelnost), nebo se session cookie přenese přes HTTP v obcházení HTTPS:

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

Top chyby v konfiguraci, které vídám na cizích serverech

1. memory_limit = -1 „pro jistotu". Znamená to „bez omezení". Jediný zacyklený skript sní veškerou RAM serveru. Mělo by tam být konkrétní číslo: 256M, 512M, 1024M.
2. max_execution_time = 0. Totéž co výše — skript bez timeoutu může viset hodiny a držet FPM worker. 60–90 sekund je rozumný rozsah pro většinu webů.
3. display_errors = On na produkci. Chyby se uživatelům zobrazují v prohlížeči spolu s cestami k souborům, verzemi knihoven a občas fragmenty SQL. Zobrazujte je jen na dev serveru. V produkci — display_errors = Off, log_errors = On.
4. pm.max_children zvolené naslepo. Buď nastavili 5 a web „padne" při prvním nárůstu provozu, nebo nastavili 200 a server se udusí. Spočtěte vzorcem ze sekce o FPM.
5. OPcache s memory_consumption=64. Výchozí hodnota z většiny tutoriálů. Pro jakýkoli reálný CMS web je to málo, cache neustále přetéká a resetuje se. Minimum 128, reálně 256–512.
6. opcache.validate_timestamps=0 bez CI/CD. Po nasazení web ukazuje starou verzi kódu a adminové zoufale hledají bugy. Buď nastavte 1, nebo nakonfigurujte automatický reload FPM po releasu.
7. JIT s buffer_size=512M, protože „víc = líp". Na CMS webu to sežere půl giga RAM zbytečně. JIT používá jen to, co skutečně potřebuje — začněte na 64–128M.
8. info.php / phpinfo.php zůstal v produkci. Dočasný soubor, který vznikl pro kontrolu, ale zapomněli ho smazat. Útočník vidí verzi PHP, všechny načtené moduly, cesty, proměnné prostředí. Mažte ihned po kontrole — o nebezpečí odhalování verzí softwaru a způsobech, jak je skrýt, jsme detailně psali v článku o ověření verze Apache.

Časté dotazy