Optimalizace web serveru

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), OS 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).

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

Volba a role webového serveru

• Nginx: event-driven, vhodný pro statický obsah, reverzní proxy a TLS terminaci; nízká režie na připojení.
• Apache: moduly a kompatibilita; pro výkon preferujte MPM event s ProxyPass před aplikační vrstvou.
• Caddy: automatický TLS, jednoduchá konfigurace, dobrý HTTP/2/3 stack.

Oddělte edge (TLS, komprese, caching) od backendu (aplikace). U dynamiky 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, header compression (HPACK), server push je dnes spíše nahrazen preload linky; aktivujte http2 na TLS vHostech.
• HTTP/3/QUIC: běží nad UDP, odolnější vůči ztrátám, nižší latence při migraci připojení; povolte jen kde je stabilní UDP a správné firewall pravidla.
• Optimalizace: používejte alt-svc hlavičky, testujte p95 latenci na mobilních sítích.

TLS 1.3, resumption a OCSP stapling

• TLS 1.3 snižuje handshake RTT, podporuje 0-RTT (pozor na opakovatelnost požadavků).
• Resumption: session tickets/IDs s rozumnou expirací; snižuje CPU.
• OCSP stapling: server přikládá status certifikátu; zkracuje TTFB.
• Curve a ciphers: 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 spojení. Reverzní proxy drží pooly k backendům: nastavte max_conns, keepalive_requests a keepalive_timeout tak, aby nedocházelo k thrashingu. Sledujte fronty (upstream queue) a nastavte limity na backlog, abyste předešli syn-flood saturaci.

Kompresní strategie: gzip a Brotli

• Výběr: Brotli pro statické textové soubory (úroveň 4–6 pro on-the-fly; 9–11 pro prekompresi), gzip pro dynamické odpovědi (úroveň 3–5).
• Rozsah: komprimujte text/html, text/css, application/javascript, application/json, image/svg+xml; nekonprimujte již komprimované formáty (JPEG/PNG/WebP/AVIF/ZIP).
• Vary: nastavte Vary: Accept-Encoding pro správnou CDN/edge kompatibilitu.

HTTP cache: Cache-Control, ETag a preloading

• Cache-Control: pro statická aktiva používejte public, max-age=31536000, immutable s content hashing v názvech souborů.
• ETag/Last-Modified: pro dynamiku uplatněte podmíněné odpovědi; minimalizujte výpočet ETag (např. size-timestamp místo full hash) u velkých souborů.
• Preload: <link rel="preload"> pro kritická aktiva; preconnect/dns-prefetch pro externí zdroje.
• Surrogate-Control: s CDN umožní odlišné TTL na edge vs. klient.

CDN a edge cachování

CDN s anycastem minimalizuje latenci a šetří zdroje originu. Využijte varianty podle hlaviček (Vary), cache keys, surrogate keys pro invalidaci po skupinách, ochranu DDoS a TLS terminaci co nejblíže uživateli. U statiky offloadujte doručování kompletně na CDN.

Statický obsah a obrázky

• Formáty: preferujte WebP/AVIF; spravujte Accept negotiation a fallbacky.
• Rozměry a lazy-load: generujte více velikostí server-side, používejte srcset a loading="lazy".
• Správa hlaviček: dlouhá cache pro verziované soubory, krátká pro neversionované.

Varnish / reverse proxy cache pro dynamiku

U publikačního CMS nasazujte Varnish nebo Nginx microcache (100–500 ms) ke snížení zátěže backendu. Řešte invalidation přes BAN/PURGE, grace mode při výpadku backendu a ESI fragmentaci složitých stránek. Dbejte na 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 = dynamic či ondemand), pm.max_children podle RAM/konkurence, zapnutý OPcache s persistencí a preloadingem.
• Node.js: běžte více procesů (cluster, PM2), udržujte non-blocking IO, omezte synchronní operace.
• JVM: nastavte velikost heapu, G1/ZGC, warmup; profilujte hot spoty.
• DB připojení: connection pooling (PgBouncer/ProxySQL), optimalizace dotazů, cachování objektů (Redis/Memcached).
• Šablony a serializace: minimalizujte práci per request, používejte připravené odpovědi a JSON streaming tam, kde to dává smysl.

Kernel, síť a I/O ladění

• Deskriptory: zvýšit limity (ulimit -n), fs.file-max.
• Backlog a fronty: net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, zapnout SYN cookies jen při DoS.
• TCP: tcp_fastopen, tcp_tw_reuse (s opatrností), tcp_fin_timeout; vypněte Nagle (TCP_NODELAY) pro latenci.
• sendfile/aio: povolit sendfile a aio pro statiku; hlídat kompatibilitu s TLS offloadem.
• Reuseport: u Nginx/Caddy aktivujte reuseport pro rozložení akceptů mezi worker procesy.
• Storage: používejte SSD/NVMe, vhodné I/O plánovače, noatime mounty pro statiku.

Konfigurace Nginx: praktické body

• Workers: worker_processes auto, worker_connections dle paměti a zátěže.
• Buffers: optimalizujte client_body_buffer_size, proxy_buffer_size, proxy_busy_buffers_size.
• Time-outy: client_body_timeout, send_timeout, proxy_read_timeout – brání visícím spojům.
• Cache: proxy_cache_path s keys_zone, proxy_cache_bypass pro 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 obsluhovat přes mod_http2 a reverzní proxy.
• mod_proxy_fcgi pro PHP-FPM; vypínat nepotřebné moduly.
• Cache: mod_cache s cache_socache pro krátké TTL; HLAVNĚ správné Cache-Control hlavičky.

Konfigurace Caddy: stručně

• Auto TLS a OCSP stapling implicitně; aktivujte encode gzip zstd (Zstandard je vhodný pro on-the-fly kompresi).
• Reverse proxy s health checky a load balancingem.

Balancování zátěže a vysoká dostupnost

• L7 LB (HAProxy, Nginx, Envoy) pro sticky-sessions přes cookies, health-checky a outlier detection.
• L4 LB (IPVS/keepalived) pro jednoduché TCP/UDP rozložení s nízkou režií.
• 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í CDN edge.
• Anycast rezolverů a autoritativních serverů; aktivní monitoring a RUM pro latence resolverů.
• DNSSEC: bezpečnostní přínos, 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, hit-rate cache a podíl cache MISS. Nastavte rozumné alerty na p95 latenci, 5xx chybovost a vyčerpání file descriptorů.

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

• Rate limiting a WAF chrání před abuse a snižují šum.
• Bot management a challenge mechanizmy redukují zbytečné requesty.
• 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ěrnou zátěž.
• Resource requests/limits tak, aby nedošlo 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í DB dotazů.
• Page cache na reverse proxy, minifikace a bundling statiky, kritické CSS inlinovat pouze uvážlivě.
• Plugin hygiena: méně je více; sledujte pomalé hooky a dotazy.

Proces optimalizace: postup krok za krokem

1. Definujte SLO (např. p95 < 200 ms pro statiku, < 500 ms pro dynamiku).
2. Změřte baseline (profiling, RUM, syntetické testy).
3. Zapněte HTTP/2, TLS 1.3, kompresi a cachování statiky.
4. Zaveďte reverse proxy cache/microcache, optimalizujte keep-alive a pooly.
5. Odstraňte blokující části aplikace, optimalizujte DB a použijte Redis.
6. Nasazením CDN snižte latenci globálně.
7. Doladění kernelu a limitů, horizontální škálování, automatizace.
8. Průběžná observabilita, regresní testy výkonu v CI.

Časté anti-patterny

• Bez verze v názvu statických souborů a krátká cache – zbytečné MISSy.
• Přebytek Set-Cookie na odpovědích, které mají být cacheované.
• Vysoké kompresní úrovně on-the-fly na dynamice → CPU bottleneck.
• Poddimenzovaný pool PHP-FPM/DB → fronty a timeouty.
• Nesynchronizovaný čas → špatná korelace a diagnostika.

Závěr

Optimalizace výkonu webového serveru je kombinací správné architektury, promyšlené konfigurace a disciplíny v měření. Postupným odstraňováním úzkých hrdel – od síťové vrstvy přes TLS, HTTP a caching až po aplikaci a databázi – dosáhnete nízké latence, vysoké propustnosti a prediktabilní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í.