Optimalizace výkonu webového serveru: cachování a komprese

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 webového serveru (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/s (RPS), data/s.
Chybovost: podíl 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).

K testování použijte nástroje jako wrk, k6, ab, vegeta. Měřte za reverzní proxy i na aplikační vrstvě a oddělte scénáře s warm cache a cold cache.

Volba a role webového serveru

Nginx: řízený událostmi, vhodný pro statický obsah, reverzní proxy a ukončení TLS; nízká režie na připojení.
Apache: moduly a kompatibilita; kvůli výkonu upřednostněte MPM event s ProxyPass před aplikační vrstvou.
Caddy: automatické TLS, jednoduchá konfigurace, kvalitní zásobník HTTP/2/3.

Oddělte edge (TLS, kompresi, cachování) 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: multiplexování, komprese hlaviček (HPACK), server push je dnes spíše nahrazen odkazy preload; aktivujte http2 na TLS vHostech.
HTTP/3/QUIC: běží nad UDP, je odolnější vůči ztrátám a při migraci připojení nabízí nižší latenci; povolte jej pouze tam, kde je UDP stabilní a pravidla firewallu jsou správně nastavena.
Optimalizace: používejte hlavičky alt-svc a testujte latenci p95 v mobilních sítích.

TLS 1.3, opětovné navázání relace a OCSP stapling

TLS 1.3 snižuje počet RTT při navazování spojení a podporuje 0-RTT (pozor na opakovatelnost požadavků).
Opětovné navázání relace: lístky/ID relací s rozumnou dobou platnosti; snižuje zatížení CPU.
OCSP stapling: server přikládá stav certifikátu; zkracuje TTFB.
Křivky a šifry: upřednostňujte x25519 a AES-GCM/CHACHA20-POLY1305.

Keep-Alive, sdružování připojení a fronty

Zapněte HTTP Keep-Alive s vyváženou dobou trvání a limitem požadavků na připojení. Reverzní proxy udržuje 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 pro backlog, abyste předešli saturaci při SYN flood útocích.

Strategie komprese: gzip a Brotli

Výběr: Brotli pro statické textové soubory (úroveň 4–6 pro kompresi za běhu; 9–11 pro předběžnou kompresi), 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-Encoding pro správnou kompatibilitu s CDN/edge.

HTTP cache: Cache-Control, ETag a předběžné načítání

Cache-Control: pro statická aktiva používejte public, max-age=31536000, immutable a v názvech souborů využívejte content hashing.
ETag/Last-Modified: pro dynamický obsah používejte podmíněné odpovědi; u velkých souborů minimalizujte výpočet ETag (např. size-timestamp místo úplného hashe).
Preload: používejte <link rel="preload"> pro kritická aktiva a preconnect/dns-prefetch pro externí zdroje.
Surrogate-Control: s CDN umožňuje nastavit odlišnou dobu platnosti v cache na edge a u klienta.

CDN a cachování na edge

CDN s anycastem minimalizuje latenci a šetří zdroje origin serveru. Využijte varianty podle hlaviček (Vary), cache keys, surrogate keys pro hromadnou invalidaci, ochranu proti DDoS a ukončení TLS co nejblíže uživateli. Doručování statického obsahu zcela přenechte CDN.

Statický obsah a obrázky

Formáty: upřednostňujte WebP/AVIF; správně nastavte vyjednávání podle hlavičky Accept a záložní varianty.
Rozměry a lazy-load: generujte více velikostí na straně serveru, používejte srcset a loading="lazy".
Správa hlaviček: nastavte dlouhou dobu cachování pro verzované soubory a krátkou pro neverzované.

Varnish / cache reverzní proxy pro dynamický obsah

U publikačního CMS nasaďte Varnish nebo microcache Nginx (100–500 ms), abyste snížili zátěž backendu. Vyřešte invalidaci pomocí BAN/PURGE, nastavte grace mode pro případ výpadku backendu a použijte fragmentaci ESI pro složité stránky. Dbejte na Vary (cookie, jazyk, zařízení) a minimalizujte zbytečné hlavičky Set-Cookie u odpovědí, které lze cachovat.

Optimalizace aplikační vrstvy

PHP-FPM: správná velikost poolu (pm = dynamic nebo ondemand), nastavení pm.max_children podle RAM a souběžnosti, zapnutý OPcache s perzistencí a přednačítáním.
Node.js: spusťte více procesů (cluster, PM2), používejte neblokující IO a omezte synchronní operace.
JVM: nastavte velikost haldy, G1/ZGC a zahřátí; profilujte horká místa.
Připojení k DB: sdružování připojení (PgBouncer/ProxySQL), optimalizace dotazů, cachování objektů (Redis/Memcached).
Šablony a serializace: minimalizujte práci při každém požadavku, používejte předpřipravené odpovědi a streamování JSON tam, kde to dává smysl.

Ladění jádra, sítě a I/O

Deskriptory: zvyšte limity (ulimit -n), fs.file-max.
Backlog a fronty: net.core.somaxconn, net.ipv4.tcp_max_syn_backlog; SYN cookies zapínejte pouze při DoS útoku.
TCP: tcp_fastopen, tcp_tw_reuse (opatrně), tcp_fin_timeout; kvůli latenci vypněte Nagleův algoritmus (TCP_NODELAY).
sendfile/aio: povolte sendfile a aio pro statický obsah; ověřte kompatibilitu s offloadem TLS.
Reuseport: v Nginx/Caddy aktivujte reuseport pro rozložení přijímání spojení mezi pracovní procesy.
Úložiště: používejte SSD/NVMe, vhodné plánovače I/O a připojujte statické svazky s volbou noatime.

Konfigurace Nginx: praktické body

Pracovní procesy: worker_processes auto, worker_connections podle paměti a zátěže.
Buffery: optimalizujte client_body_buffer_size, proxy_buffer_size, proxy_busy_buffers_size.
Časové limity: client_body_timeout, send_timeout, proxy_read_timeout – zabraňují dlouho visícím spojením.
Cache: proxy_cache_path s keys_zone, proxy_cache_bypass pro přihlášené uživatele.
Bezpečnost: omezení hlaviček a velikosti těla, omezování rychlosti (limit_req) – chrání výkon.

Apache: tipy pro výkon

MPM event místo prefork; statický obsah obsluhujte pomocí mod_http2 a reverzní proxy.
mod_proxy_fcgi pro PHP-FPM; vypněte nepotřebné moduly.
Cache: mod_cache s cache_socache pro krátkou dobu platnosti; PŘEDEVŠÍM správné hlavičky Cache-Control.

Konfigurace Caddy: stručně

Automatické TLS a OCSP stapling jsou zapnuté implicitně; aktivujte encode gzip zstd (Zstandard se hodí pro kompresi za běhu).
Reverzní proxy s kontrolami stavu a vyvažováním zátěže.

Vyvažování zátěže a vysoká dostupnost

L7 LB (HAProxy, Nginx, Envoy) pro relace zachovávané pomocí cookies, kontroly stavu a detekci odlehlých hodnot.
L4 LB (IPVS/keepalived) pro jednoduché rozkládání TCP/UDP s nízkou režií.
Přepnutí při selhání: anycast IP, BGP nebo směrování DNS podle stavu (s rozumnou dobou platnosti TTL).

DNS a domény: vliv na výkon

TTL: krátká TTL u dynamických záznamů (A/AAAA/CNAME) pro řízené přepnutí při selhání; delší TTL pro stabilní CDN edge.
Anycast pro DNS resolvery a autoritativní servery; aktivní monitoring a RUM pro měření latence resolverů.
DNSSEC: přínos pro bezpečnost, při správné konfiguraci minimální dopad na latenci.

Observabilita: logy, metriky, trasování

Implementujte metriky (Prometheus/OpenMetrics), distribuované trasování (OpenTelemetry) a korelaci s logy. Sledujte vytížení pracovních procesů, délku front, chování GC, míru zásahů cache a podíl chybných načtení z cache (MISS). Nastavte rozumná upozornění na latenci p95, chybovost 5xx a vyčerpání deskriptorů souborů.

Bezpečnostní opatření podporující výkon

Omezování rychlosti a WAF chrání před zneužitím a snižují nežádoucí provoz.
Správa botů a mechanismy challenge omezují zbytečné požadavky.
HSTS a moderní TLS snižují počet opětovných vyjednávání a přesměrování.

Specifika Kubernetes a kontejnerů

Ingress (nginx/contour/traefik/envoy) s keep-alive a bufferováním; Pod Topology Spread pro rovnoměrné rozložení zátěže.
Požadavky/limity prostředků nastavte tak, aby nedocházelo k omezování CPU ani ukončování procesů kvůli nedostatku paměti (OOM killům).
Sidecar pro kompresi/cachování používejte pouze tehdy, pokud přináší přínos; zbytečné sidecary zvyšují latenci.

WordPress/typické CMS: rychlé zlepšení

OPcache a object cache (Redis) pro snížení počtu dotazů do DB.
Page cache na reverzní proxy, minifikace a sdružování statických souborů; kritické CSS vkládejte přímo do stránky pouze uvážlivě.
Hygiena pluginů: méně je více; sledujte pomalé hooky a dotazy.

Proces optimalizace: postup krok za krokem

Definujte SLO (např. p95 < 200 ms pro statický obsah, < 500 ms pro dynamický obsah).
Změřte výchozí stav (profilování, RUM, syntetické testy).
Zapněte HTTP/2, TLS 1.3, kompresi a cachování statického obsahu.
Zaveďte cache reverzní proxy/microcache, optimalizujte keep-alive a pooly.
Odstraňte blokující části aplikace, optimalizujte DB a použijte Redis.
Nasazením CDN globálně snižte latenci.
Vylaďte jádro a limity, horizontálně škálujte a automatizujte.
Průběžně zajišťujte observabilitu a provádějte regresní testy výkonu v CI.

Časté anti-patterny

Statické soubory bez verze v názvu a krátká doba cachování – zbytečné cache MISS.
Příliš mnoho hlaviček Set-Cookie u odpovědí, které mají být cachované.
Vysoká úroveň komprese za běhu u dynamického obsahu → úzké hrdlo CPU.
Poddimenzovaný pool PHP-FPM/DB → fronty a časové limity.
Nesynchronizovaný čas → špatná korelace a diagnostika.

Závěr

Optimalizace výkonu webového serveru je kombinací správné architektury, promyšlené konfigurace a důsledného měření. Postupným odstraňováním úzkých hrdel – od síťové vrstvy přes TLS, HTTP a cachování až po aplikaci a databázi – dosáhnete nízké latence, vysoké propustnosti a předvídatelného chování i při špičkách. Klíčem je průběžná observabilita, automatizované testy výkonu a jednoduchost řešení: méně komponent, více dat pro rozhodování.