Proč optimalizovat výkon webového serveru
Výkon webového serveru ovlivňuje uživatelskou zkušenost, SEO, provozní náklady i konverze. Optimalizace zahrnuje architekturu (reverse proxy, CDN), konfiguraci webserveru (Nginx/Apache/Caddy), operační systém a síťové zásobníky, TLS, cachování a kompresi, práci se statickými soubory i aplikační vrstvou (PHP-FPM, Node.js, JVM). Cílem je minimalizovat latenci, maximalizovat propustnost a stabilitu při zachování bezpečnosti.
Cílové metriky a měření
- Latence: p50/p90/p95/p99 doba odezvy; sledujte zvlášť TTFB.
- Propustnost: požadavky za sekundu (RPS), data za sekundu.
- Chybovost: podíl stavových kódů 4xx/5xx, saturace front.
- Využití zdrojů: CPU, paměť, IO, síť, otevřené deskriptory.
- SLA/SLO: cílové hodnoty a rozpočty chyb (error budgets).
Pro testování používejte nástroje typu wrk, k6, ab, vegeta. Měřte jak za reverzní proxy, tak i na aplikační vrstvě, oddělte scénáře warm cache a cold cache.
Volba a role webového serveru
- Nginx: event-driven architektura, vhodný pro statický obsah, reverzní proxy a TLS terminaci; nízká režie na připojení.
- Apache: modulární systém a kompatibilita; pro výkon preferujte MPM event s ProxyPass před aplikační vrstvou.
- Caddy: automatický TLS, jednoduchá konfigurace, kvalitní HTTP/2 a HTTP/3 stack.
Oddělte edge funkce (TLS, komprese, caching) od backendu (aplikace). Pro dynamický obsah používejte reverzní proxy (Nginx/Caddy/Varnish) před aplikačním serverem (PHP-FPM, uWSGI/Gunicorn, Node.js, Java).
HTTP/2 a HTTP/3 (QUIC)
- HTTP/2: multiplexing, komprese hlaviček (HPACK), server push je dnes častěji nahrazen preload linkami; aktivujte
http2na TLS virtual hostech. - HTTP/3/QUIC: funguje nad UDP, je odolnější vůči ztrátě paketů, nižší latence při migraci připojení; povolujte pouze tam, kde je stabilní UDP a správně nastavená firewall pravidla.
- Optimalizace: používejte
alt-svchlavičky, testujte latenci p95 v mobilních sítích.
TLS 1.3, resumption a OCSP stapling
- TLS 1.3 snižuje počet RTT během handshake, podporuje 0-RTT (pozor na možné opakování požadavků).
- Resumption: session tickets/ID s rozumnou expirací; snižuje zatížení CPU.
- OCSP stapling: server přikládá stav certifikátu OCSP; zkracuje TTFB.
- Kurvy a šifry: preferujte x25519 a AES-GCM/CHACHA20-POLY1305.
Keep-Alive, connection pooling a fronty
Zapněte HTTP Keep-Alive s vyváženou dobou trvání a limitem požadavků na jedno spojení. Reverzní proxy udržují pooly připojení k backendům: nastavte max_conns, keepalive_requests a keepalive_timeout tak, aby nedocházelo k thrashingu. Sledujte fronty (upstream queue) a nastavte limity pomocí backlog, abyste předešli saturaci SYN-flood útoky.
Kompresní strategie: gzip a Brotli
- Výběr: Brotli pro statické textové soubory (úroveň 4–6 pro on-the-fly, 9–11 pro předkompresi), gzip pro dynamické odpovědi (úroveň 3–5).
- Rozsah: komprimujte
text/html,text/css,application/javascript,application/json,image/svg+xml; nekomprimujte již komprimované formáty (JPEG/PNG/WebP/AVIF/ZIP). - Vary: nastavte
Vary: Accept-Encodingpro správnou kompatibilitu s CDN a edge servery.
HTTP cache: Cache-Control, ETag a preloading
- Cache-Control: pro statická aktiva používejte
public, max-age=31536000, immutablea content hashing ve jménech souborů. - ETag/Last-Modified: u dynamického obsahu využívejte podmíněné odpovědi; minimalizujte výpočet ETag (například size-timestamp místo plného hashování) u velkých souborů.
- Preload:
<link rel="preload">pro kritická aktiva;preconnectadns-prefetchpro externí zdroje. - Surrogate-Control: s CDN umožňuje rozdílné TTL na edge versus klientovi.
CDN a edge cachování
CDN s anycast technologií minimalizuje latenci a šetří zdroje originálního serveru. Využijte různé varianty podle hlaviček (Vary), cache keys, surrogate keys pro kolektivní invalidaci, ochranu proti DDoS a TLS terminaci co nejblíže uživateli. U statického obsahu kompletně přesuňte doručování na CDN.
Statický obsah a obrázky
- Formáty: preferujte WebP a AVIF; spravujte
Acceptnegotiation a fallback řešení. - Rozměry a lazy load: generujte více velikostí na straně serveru, používejte atributy
srcsetaloading="lazy". - Správa hlaviček: dlouhá cache pro verziované soubory, krátká cache pro neverziované.
Varnish / reverzní proxy cache pro dynamiku
U publikačních CMS nasazujte Varnish nebo Nginx microcache (100–500 ms) ke snížení zátěže backendu. Řešte invalidaci pomocí BAN/PURGE, grace mode při výpadku backendu a ESI fragmentaci komplexních stránek. Dbejte na správné použití Vary (cookie, jazyk, zařízení) a minimalizujte zbytečné Set-Cookie u cacheovatelných odpovědí.
Optimalizace aplikační vrstvy
- PHP-FPM: správná velikost poolu (
pm = dynamicneboondemand),pm.max_childrennastavte dle RAM a konkurenční zátěže, zapnutý OPcache s perzistencí a preloadingem. - Node.js: provozujte více procesů (cluster, PM2), udržujte non-blocking IO, omezte synchronní operace.
- JVM: nastavte velikost heapu, G1/ZGC, warmup; profilujte hot spoty.
- Připojení k databázi: connection pooling (PgBouncer/ProxySQL), optimalizace dotazů, cachování objektů (Redis/Memcached).
- Šablony a serializace: minimalizujte práci na každý request, používejte připravené odpovědi a JSON streaming tam, kde je to vhodné.
Kernel, síť a I/O ladění
- Deskriptory: zvyšte limity (
ulimit -n),fs.file-max. - Backlog a fronty:
net.core.somaxconn,net.ipv4.tcp_max_syn_backlog, zapínejte SYN cookies pouze při DoS útocích. - TCP:
tcp_fastopen,tcp_tw_reuse(s opatrností),tcp_fin_timeout; vypněte Nagle algoritmus (TCP_NODELAY) pro snížení latence. - sendfile/aio: povolte
sendfileaaiou statického obsahu; hlídejte kompatibilitu s TLS offloadem. - Reuseport: u Nginx/Caddy aktivujte
reuseportpro rovnoměrné rozložení akceptů mezi pracovní procesy. - Storage: používejte SSD/NVMe disky, vhodné I/O plánovače, mounty s noatime pro statický obsah.
Konfigurace Nginx: praktické body
- Pracovní procesy:
worker_processes auto,worker_connectionsupravte dle paměti a zátěže. - Buffery: optimalizujte
client_body_buffer_size,proxy_buffer_size,proxy_busy_buffers_size. - Timeouty:
client_body_timeout,send_timeout,proxy_read_timeout– aby se zabránilo visícím spojům. - Cache:
proxy_cache_paths keys_zone,proxy_cache_bypasspro přihlášené uživatele. - Bezpečnost: omezení hlaviček, velikosti těla, rate limiting (
limit_req) – chrání výkon.
Apache: výkonové tipy
- MPM event místo prefork; statiku obsluhujte přes
mod_http2a reverzní proxy. - mod_proxy_fcgi pro PHP-FPM; vypínejte nepotřebné moduly.
- Cache:
mod_cachescache_socachepro krátkodobou cache; především správné Cache-Control hlavičky.
Konfigurace Caddy: stručně
- Automatický TLS a OCSP stapling implicitně; aktivujte
encode gzip zstd(Zstandard je vhodný pro on-the-fly kompresi). - Reverzní proxy s health checky a load balancingem.
Balancování zátěže a vysoká dostupnost
- L7 load balancer (HAProxy, Nginx, Envoy) pro sticky sessions přes cookies, health-checky a outlier detection.
- L4 load balancer (IPVS/keepalived) pro jednoduché TCP/UDP rozložení se nízkou režii.
- Failover: anycast IP, BGP, nebo DNS health-based směrování (s rozumnými TTL).
DNS a domény: vliv na výkon
- TTL: krátká TTL u dynamických záznamů (A/AAAA/CNAME) pro řízený failover; delší TTL pro stabilní poli CDN edge.
- Anycast resolverů a autoritativních serverů; aktivní monitoring a RUM pro latenci resolverů.
- DNSSEC: přináší bezpečnostní benefit, minimální dopad na latenci při správné konfiguraci.
Observabilita: logy, metriky, trasy
Implementujte metriky (Prometheus/OpenMetrics), distribuované trasování (OpenTelemetry) a korelaci s logy. Sledujte saturaci workerů, délku front, chování GC, míru zásahů cache a podíl cache MISS. Nastavte rozumné alerty na latenci p95, chybovost 5xx a vyčerpání file descriptorů.
Bezpečnostní opatření podporující výkon
- Rate limiting a WAF chrání před zneužitím a snižují šum.
- Bot management a challenge mechanismy redukují zbytečné požadavky.
- HSTS a moderní TLS snižují renegociace a přesměrování.
Specifika pro Kubernetes a kontejnery
- Ingress (nginx/contour/traefik/envoy) s keep-alive a bufferingem; Pod Topology Spread pro rovnoměrné rozložení zátěže.
- Resource requests/limits, aby nedocházelo k throttlingu CPU a OOM killům.
- Sidecar pro kompresi/caching pouze pokud přináší benefit; zbytečné sidecary zvyšují latenci.
WordPress/typické CMS: rychlá výhra
- OPcache a object cache (Redis) pro snížení dotazů do databáze.
- Page cache na reverzní proxy, minifikace a bundling statických souborů, kritické CSS inline s rozmyslem.
- Pluginová hygiena: méně znamená více; sledujte pomalé hooky a dotazy.
Proces optimalizace: postup krok za krokem
- Definujte SLO (například p95 < 200 ms pro statický obsah, < 500 ms pro dynamický obsah).
- Změřte výchozí stav (profilování, RUM, syntet



























