Konfigurace serveru pro high-traffic: CPU, RAM, NVMe, tuning

Když server přestává stíhat

Web roste — a to je dobře. Dokud server stíhá. Jednoho dne provoz vzroste, stránky se začnou načítat pomaleji, CPU jde do červené zóny, databáze zpomaluje. Ten „výkonný server", který měl ještě včera rezervu — teď sotva dýchá.

Zní to povědomě? Tohle není katastrofa — je to signál k přehodnocení konfigurace. Protože nejde o to „koupit dražší", ale o to správně nakonfigurovat.

Za roky práce s high-traffic projekty jsme viděli stovky případů, kdy správný tuning dal lepší výsledek než upgrade hardwaru. Server za 50 $/měsíc s optimální konfigurací často předběhne server za 200 $ s výchozím nastavením.

Co je high-traffic?

Přesné číslo neexistuje. Jeden web padá při 2 000 současných uživatelích, jiný zvládne 50 000. Vše závisí na třech faktorech:

• Kolik současných požadavků server zpracovává
• Jak se chová vaše CMS nebo aplikace
• Kolik „těžkého" obsahu — obrázků, skriptů, dotazů do databáze

Pro blog je 10 000 návštěvníků nic. Pro internetový obchod s filtry, synchronizací skladů a dynamickými cenami — to je už vážná zátěž. Jeden požadavek na hlavní stránku blogu je jeden SELECT z databáze. Jeden požadavek na katalog Magenta s filtry je desítky dotazů, přepočet cen, kontrola skladových zásob.

Tento průvodce vám pomůže pochopit konfiguraci serveru pro projekty s vážným provozem — od výběru hardwaru po jemné ladění softwaru.

Procesor: nejen jádra

Mnozí se dívají pouze na počet jader — a to je chyba. V roce 2026 je nejdůležitější výkon jednoho vlákna (single-thread performance). Ten určuje, jak se bude PHP, Python nebo Node.js chovat pod zátěží.

PHP vykonává každý požadavek v jednom vlákně. Pokud máte 32 pomalých jader místo 8 rychlých — PHP bude zpracovávat každý jednotlivý požadavek pomaleji. Paralelismus pomáhá jen když je mnoho současných požadavků, ale každý z nich stále závisí na rychlosti jednoho jádra.

Orientační doporučení:

• 4–8 jader — malé firemní weby, blogy, lehké CMS
• 12–16 jader — střední internetové obchody, SaaS projekty
• 24+ jader — kontejnery, streaming, analytika, velké databáze

Někdy 16jádrový fyzický server pracuje lépe než 32jádrový virtuální. Důvod — virtualization overhead. Část výkonu se ztrácí mezi vrstvami virtualizace. Na VPS sdílíte fyzické zdroje s ostatními klienty, což vytváří dodatečnou latenci.

Vlákna (threads) jsou také důležitá, ale pouze pokud je software využívá. Node.js, Go, Nginx — ano. WordPress — bohužel ne. Typický WordPress neumí paralelizovat jeden požadavek na více vláken — prostě čeká, až databáze vrátí výsledek.

Paměť a caching

RAM je kyslík pro server. Když jí není dost, systém začne zapisovat dočasná data na disk (swap) a web „umírá" na latenci. Swap na NVMe je stále stokrát pomalejší než RAM.

Orientace pro výběr RAM:

• 8 GB — malý WordPress nebo firemní web
• 16–24 GB — internetový obchod, SaaS
• 32–64 GB — velké databáze, analytika, video

Ale ani 64 GB nezachrání, pokud není caching. Redis, Memcached, Varnish — to je to, co skutečně odlehčí CPU a databázi. Bez cache každý požadavek jde do databáze, PHP generuje stránku znovu, server dělá stejnou práci tisíckrát.

Jak funguje caching

Redis — ukládá výsledky dotazů do databáze, uživatelské relace, object cache. Jeden dotaz do Redis trvá mikrosekundy, dotaz do MySQL milisekundy. Rozdíl 1000×.

FastCGI Cache — Nginx ukládá hotovou HTML stránku a doručuje ji bez volání PHP vůbec. Pro anonymní uživatele je to ideální řešení.

OPcache — cachuje zkompilovaný PHP kód. Bez něj PHP překompiluje každý soubor při každém požadavku.

NVMe: rychlost, na kterou si zvyknete

Kdo přešel z SSD na NVMe — zpátky se nevrací. Rozdíl není v procentech, ale v násobcích — zejména pro databáze a logy. Běžný SATA SSD dává 500–600 MB/s sekvenčního čtení a ~50 000 IOPS. NVMe — 3000–7000 MB/s a 500 000+ IOPS.

NVMe pracuje přímo přes sběrnici PCIe, bez omezení SATA řadiče. Výsledek: nižší latence, více I/O operací za sekundu, stabilnější práce pod zátěží. Pro databázi je to kritické — každý dotaz je přístup na disk.

RAID konfigurace

Důležité: nešetřete na spolehlivosti.

• RAID-1 (zrcadlo) — minimum pro produkci. Dva disky s identickými daty. Jeden selže — běžíte na druhém
• RAID-10 — pro maximální výkon a spolehlivost. Kombinace zrcadla a stripe
• RAID-0 — rychlý, ale při selhání jednoho disku přijdete o VŠE. Pouze pro dočasná data

V jednom projektu přenesení eCommerce webu z SSD pole na NVMe RAID-1 snížilo průměrný čas načítání stránky z 1,9 na 1,2 sekundy. Rozdíl je zejména patrný na stránkách katalogu s filtry — tam je hodně náhodných čtení z databáze.

Síť: úzké místo, na které se zapomíná

Někdy je všechno zdánlivě v pořádku — CPU je normální, RAM stačí, cache je nakonfigurovaná — ale web stále zpomaluje. Důvod je jednoduchý: úzká šířka pásma. Zejména je to patrné při velkém počtu současných spojení nebo přenosu velkých souborů.

100 Mbit/s v roce 2026 je úroveň kanceláře, ne produkce. Při 100 Mbit/s můžete doručit maximálně ~12 MB/s. Pokud průměrná stránka váží 2 MB (s obrázky), můžete současně obsluhovat pouze 6 uživatelů na plné rychlosti.

Pro stabilní provoz potřebujete:

• Minimum 1 Gbit/s port — standard pro jakýkoli vážný projekt
• Podpora HTTP/3 (QUIC) — rychlejší navázání spojení, lepší práce na mobilních sítích
• Připojení CDN pro globální publikum — statiku doručuje server nejbližší uživateli

CDN může převzít 60–80 % zátěže, pokud je vaše publikum geograficky rozptýlené. Obrázky, CSS, JavaScript, video — vše se cachuje na edge serverech po celém světě. Hlavní server se zabývá pouze dynamickým obsahem.

Hostiserver kombinuje CDN s NVMe konfiguracemi — to odstraňuje úzká místa bez složitých řešení. Nastavení zabere pár minut přes ovládací panel.

Tuning: rozdíl mezi „funguje" a „létá"

I ten nejdražší hardware může zpomalovat kvůli špatné konfiguraci. Typická situace: koupili výkonný server, nainstalovali CMS, nechali výchozí nastavení MySQL a PHP-FPM — a diví se proč je to pomalé. Výchozí hodnoty jsou navrženy pro minimální spotřebu zdrojů, ne pro výkon.

PHP-FPM (příklad pro 16 GB RAM)

Používáme dynamický režim (pm = dynamic) pro smíšené zátěže nebo static pro vysoce zatížené projekty s předvídatelným provozem:

[www]
pm = dynamic
pm.max_children = 150
; Vzorec: (Volná RAM) / (velikost PHP procesu ~60-100MB)
; Pro 16GB server s 12GB volné RAM: 12000/80 ≈ 150
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
; Restart workerů pro zamezení únikům paměti
pm.max_requests = 1000
; Timeout pro dlouhé skripty (import, generování reportů)
request_terminate_timeout = 300

Proč je pm.max_requests důležitý: PHP procesy mohou „téct" — postupně zabírat více paměti kvůli špatně napsaným pluginům nebo rozšířením. Bez omezení za pár hodin sežerou veškerou RAM. S pm.max_requests = 1000 se každý worker restartuje po 1000 zpracovaných požadavcích.

MySQL / MariaDB

[mysqld]
# Hlavní parametr — 50-70% z celkové RAM
# Pro 16GB server kde MySQL je jediný těžký proces
innodb_buffer_pool_size = 10G
# 25% z buffer pool pro zrychlení zápisů
innodb_log_file_size = 2G
# Závisí na počtu PHP procesů
# Každý PHP worker může držet 1-2 spojení
max_connections = 500
# Logování pomalých dotazů — POVINNÉ
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

O slow_query_log: toto je váš hlavní diagnostický nástroj. Všechny dotazy delší než long_query_time sekund jdou do logu. Pak je analyzujete přes mysqldumpslow nebo pt-query-digest a optimalizujete nejpomalejší.

Nginx

worker_processes auto;  # Jeden na jádro CPU
worker_connections 4096; # Max spojení na worker
# Zamezení zápisu velkých PHP odpovědí do souborů
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
# Gzip pro úsporu bandwidth
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json 
           application/javascript text/xml 
           application/xml image/svg+xml;
# Brotli je ještě efektivnější (pokud je nainstalován modul)
# brotli on;
# brotli_comp_level 6;

Tyto „drobnosti" mohou zdvojnásobit propustnost bez upgrade hardwaru. Jeden klient po správném nastavení těchto parametrů získal nárůst ze 40 na 95 RPS na stejném serveru.

Monitoring: jak poznat že server nestíhá

Známky problémů

• CPU > 80 % po dobu 5+ minut — Warning
• CPU > 95 % — Critical, potřeba okamžité reakce
• RAM > 90 % (kromě cache) — server začíná swapovat
• Disk Space < 10 % — nejčastější příčina pádu databáze
• HTTP 5xx > 1 % provozu — něco je vážně špatně

Steal Time (%st) — skrytý nepřítel VPS

Pokud v htop nebo top vidíte Steal Time > 1–2 % — sousedé v cloudu vám berou CPU zdroje. To je známka že je čas přejít na Dedicated.

Nejdůležitější metriky pro high-traffic

1. Average Response Time (Latency) — pokud je hardware v pořádku, ale Latency roste — problém je v kódu nebo blokováních v DB
2. Error Rate — procento 4xx/5xx chyb
3. TTFB (Time to First Byte) — čas do prvního bajtu odpovědi

Pravidlo: pokud kterýkoli z těchto ukazatelů je v červené zóně déle než 5 minut — to už není „špičkový moment", ale systémový problém.

Zátěžové testování

Před spuštěním reklamy nebo očekávanou sezónní špičkou — otestujte server. Lepší zjistit problémy v testu než během výprodeje. Load testing ukazuje skutečný limit vašeho serveru — kolik současných uživatelů zvládne než začne zpomalovat.

Nástroje pro testování

k6 (doporučujeme) — nejmodernější nástroj. Scénáře v JavaScriptu, vynikající reporty, snadná integrace do CI/CD. Můžete popsat realistické chování uživatele: navštívil hlavní stránku, přešel do katalogu, přidal zboží do košíku.

# Instalace
sudo apt install k6
# Jednoduchý test se 100 virtuálními uživateli po dobu 30 sekund
k6 run --vus 100 --duration 30s script.js

wrk — pro kontrolu čisté propustnosti. Nejrychlejší ze všech, ale bez složitých scénářů:

# 12 vláken, 400 spojení, 30 sekund
wrk -t12 -c400 -d30s https://example.com/

Locust — pokud potřebujete složité scénáře chování uživatelů. Napsán v Pythonu, má webové rozhraní pro sledování testu v reálném čase.

Apache Benchmark (ab) — nejjednodušší varianta, již nainstalovaná na většině serverů:

# 1000 požadavků, 100 současných
ab -n 1000 -c 100 https://example.com/

Co se považuje za normální výsledek

Pokud jsou vaše výsledky výrazně nižší — je prostor pro optimalizaci. Věnujte pozornost nejen RPS, ale i percentile latency: p95 a p99 ukazují čas odpovědi pro 95 % a 99 % požadavků. Pokud je průměrný čas 200 ms, ale p99 je 5 sekund, část uživatelů dostává velmi pomalé odpovědi.

Scaling: když upgrade nepomáhá

Dříve nebo později server narazí na strop. Ani výkonný hardware nezachrání, pokud architektura není rozdělena. Jsou dvě cesty: vertikální škálování (více zdrojů na jednom serveru) a horizontální (více serverů).

Kdy přejít z VPS na Dedicated

VPS je virtuální stroj na sdíleném fyzickém serveru. Sdílíte zdroje s ostatními klienty. Dedicated — celý fyzický server je váš. Kdy VPS nestačí:

• Provoz: stabilně přes 100–150 RPS nebo 50 000+ unikátních návštěvníků denně
• Steal Time (%st): v top/htop ukazuje > 1–2 % — sousedé vám berou CPU zdroje
• I/O Wait: vysoké latence diskového subsystému kvůli sdílenému storage
• Nestabilní TTFB: čas odezvy „plave" bez viditelných příčin ve vašem kódu

Steal Time (%st) — hlavní indikátor. Pokud vidíte více než 1–2 % stabilně — sousedé v cloudu vám berou zdroje. Na Dedicated tento problém neexistuje.

Horizontální škálování

Když CPU drží nad 70 % a stránky jsou stále pomalé — čas rozdělit architekturu:

• Databáze na samostatný server — nejčastěji první co se vynáší. MySQL/PostgreSQL dostane vyhrazené zdroje, nekonkuruje s PHP o CPU
• Statika na CDN — obrázky, CSS, JS doručuje CDN, hlavní server se zabývá pouze dynamikou
• Redis na samostatný server — při velkých objemech cache
• Load balancer — rozděluje provoz mezi více web serverů

Je to složitější na nastavení a údržbu, ale dává stabilitu a možnost škálovat dále. Všechny velké projekty procházejí touto fází — jinak uvíznou na hranici jednoho serveru.

Časté chyby

Příklady konfigurací které fungují

Toto jsou reálné produkční konfigurace, které přežily špičky provozu bez pádů.

Často kladené otázky