Kolik souběžných uživatelů zvládne VPS: jak to spočítat

Od uživatelů k požadavkům

„Souběžní uživatelé“ označují podle toho, kdo mluví, tři různé veličiny:

• Registrované účty: server nic nestojí, dokud se nepřihlásí.
• Uživatelé aktivní ve stejnou chvíli: lidé, kteří procházejí web, čtou, vyplňují formulář. Každý z nich čas od času pošle požadavek, typicky jednou za 10 až 30 sekund, a v moderní aplikaci k tomu několik volání API na každou obrazovku.
• Rozpracované požadavky: ty, které server v daném okamžiku počítá. Je to jediná veličina, která spotřebovává procesor a paměť.

Mezi nimi se přechází pomocí Littleova zákona: počet rozpracovaných požadavků se rovná propustnosti v požadavcích za sekundu vynásobené průměrnou dobou trvání požadavku.

Příklad. 600 uživatelů aktivních ve stejnou chvíli, z nichž každý vyvolá požadavek jednou za 20 sekund, dává 30 požadavků za sekundu. Pokud každý požadavek trvá 100 ms, má server v průměru rozpracované jen 3 požadavky. To podstatné leží jinde: ve špičkách a v pomalých požadavcích.

Co zvládne jeden vCPU

Požadavek zaměstnává procesor po dobu svého výpočtu: provedení kódu, dotaz do databáze, sestavení odpovědi. Jeden vCPU tedy zpracuje nanejvýš 1 000 ÷ t požadavků za sekundu, kde t je doba výpočtu jednoho požadavku v milisekundách. Čas strávený čekáním (na externí API, na disk) procesor nezaměstnává, ale zaměstnává worker.

S těmito řády zaberou 30 požadavků API za sekundu s 10 ms výpočtu 30 % jediného vCPU. Stejných 30 požadavků za sekundu na stránky WordPressu bez cache vyžaduje 3 až 9 vCPU. Cache stránek slouží právě k tomu, aby se stránka přesunula ze čtvrtého řádku tabulky na druhý.

Co zvládne paměť

Každý rozpracovaný požadavek obsluhuje worker a workery zabírají paměť, ať pracují, nebo ne. Počet paralelně zpracovávaných požadavků často určuje spíše paměť než procesor:

• PHP-FPM: jeden proces na každý rozpracovaný požadavek, každý 40 až 80 MB. pm.max_children určuje strop: 20 procesů znamená 800 MB až 1,6 GB.
• Python (Gunicorn, Uvicorn): dokumentace Gunicornu doporučuje začít s (2 × počet jader) + 1 workery, každý po 80 až 200 MB. Asynchronní worker udrží mnoho čekajících požadavků s pamětí jediného procesu.
• Node.js: jediný proces udrží tisíce čekajících připojení, ale využívá jen jedno jádro; režim cluster nebo PM2 spustí jeden proces na každý vCPU.
• Databáze: PostgreSQL otevírá jeden proces na každé připojení a ve výchozím nastavení jich přijímá 100. Od několika desítek aktivních připojení výš pomůže pooler připojení, jako je PgBouncer, víc než zvýšení max_connections.

Trvalá připojení (websockety, notifikace v reálném čase) se počítají zvlášť: jsou otevřená nepřetržitě, spotřebují málo procesoru a každé několik desítek kilobajtů paměti. Server Node.js jich udrží tisíce v několika stovkách MB.

Skutečná úzká hrdla

V reálné aplikaci se server málokdy zahltí tam, kde to čekáte. Nejčastější příčiny, v pořadí, v jakém je hledat:

1. Pomalý dotaz SQL: chybějící index promění dotaz na 2 ms v dotaz na 2 sekundy, který drží worker i připojení. Na PostgreSQL ho odhalí pg_stat_statements, na MySQL log pomalých dotazů.
2. Kaskádové dotazy (problém N+1): stránka, která spouští jeden dotaz na každý zobrazený řádek, jich spustí stovky.
3. Synchronní externí volání: platební API nebo API umělé inteligence, které odpovídá 3 sekundy, zablokuje synchronní worker na 3 sekundy.
4. Náročná zpracování uvnitř požadavku: odesílání e-mailů, změna velikosti obrázků, generování PDF; ta patří do fronty úloh.
5. Chybějící cache: stránky stejné pro všechny návštěvníky se obsluhují z cache, statické soubory přímo webovým serverem.

Ověření: zátěžový test

Řády dávají první odhad velikosti; zátěžový test dává tu skutečnou. Princip: simulovat stále více uživatelů na kopii aplikace a zaznamenat okamžik, kdy doba odezvy prudce vzroste.

wrk -t2 -c50 -d30s --latency https://preprod.vas-web.com/

Pro celý průchod aplikací (přihlášení, procházení, vyhledávání) popíše k6 scénář v JavaScriptu a zátěž zvyšuje po stupních:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://preprod.vas-web.com/');
  sleep(15);
}

• Testujte kopii, ne produkci, a upozorněte svého poskytovatele, pokud test míří na server, který provozuje.
• Spouštějte test z jiného stroje, než je testovaný server, jinak mu nástroj bere jeho vlastní prostředky.
• Sledujte 95. percentil doby odezvy, ne průměr: ten odpovídá zkušenosti vašich nejhůře obsloužených uživatelů.
• Během testu sledujte server: htop pro procesor, free -h pro paměť, logy pro chyby.

Když zátěž roste

Pořadí, které stojí nejméně a přináší nejvíc:

1. Ukládat do cache, co to dovolí (stránky, fragmenty, výsledky dotazů), a opravit pomalé dotazy.
2. Nastavit počet workerů podle dostupné paměti a procesoru.
3. Přejít na vyšší velikost: více vCPU a paměti, bez jakékoli změny v aplikaci.
4. Umístit databázi na vlastní server.
5. Rozložit aplikaci na několik serverů za load balancerem.

První tři kroky pokryjí velkou většinu firemních aplikací, webů a API: několik stovek uživatelů aktivních ve stejnou chvíli zvládne jediný dobře nastavený server.