Koľko súčasných používateľov zvládne VPS: urobte si výpočet

Od používateľov k požiadavkám

„Súčasní používatelia“ označujú tri rôzne veličiny podľa toho, kto hovorí:

• Registrované účty: server nestoja nič, kým sa neprihlásia.
• Používatelia aktívni v rovnakom čase: ľudia, ktorí prechádzajú stránky, čítajú, vypĺňajú formulár. Každý z nich z času na čas pošle požiadavku, zvyčajne každých 10 až 30 sekúnd, v modernej aplikácii k tomu niekoľko volaní API na každú obrazovku.
• Rozpracované požiadavky: tie, ktoré server v danom okamihu počíta. Je to jediná veličina, ktorá spotrebúva procesor a pamäť.

Z jednej na druhú sa prechádza Littleovým zákonom: počet rozpracovaných požiadaviek sa rovná priepustnosti v požiadavkách za sekundu vynásobenej priemerným trvaním jednej požiadavky.

Príklad. 600 používateľov aktívnych v rovnakom čase, z ktorých každý spustí požiadavku každých 20 sekúnd, vytvorí 30 požiadaviek za sekundu. Ak každá požiadavka trvá 100 ms, server má v priemere rozpracované len 3 požiadavky. Podstatné je inde: v špičkách a v pomalých požiadavkách.

Koľko zvládne jeden vCPU

Požiadavka zamestná procesor počas svojho výpočtu: vykonanie kódu, dopyt do databázy, zostavenie odpovede. Jeden vCPU teda spracuje najviac 1 000 ÷ t požiadaviek za sekundu, kde t je čas výpočtu jednej požiadavky v milisekundách. Čas strávený čakaním (na externé API, na disk) procesor nezamestnáva, ale zamestnáva worker.

S týmito rádovými hodnotami zamestná 30 požiadaviek API za sekundu s 10 ms výpočtu 30 % jediného vCPU. Rovnakých 30 požiadaviek za sekundu na stránky WordPressu bez cache si vyžiada 3 až 9 vCPU. Cache stránok slúži práve na to, aby sa stránka presunula zo štvrtého riadku tabuľky na druhý.

Koľko zvládne pamäť

Každú rozpracovanú požiadavku obsluhuje worker a workery zaberajú pamäť, či práve pracujú, alebo nie. Počet paralelne spracúvaných požiadaviek často určuje skôr pamäť než procesor:

• PHP-FPM: jeden proces na rozpracovanú požiadavku, každý 40 až 80 MB. Strop určuje pm.max_children: 20 procesov znamená 800 MB až 1,6 GB.
• Python (Gunicorn, Uvicorn): dokumentácia Gunicornu odporúča začať s (2 × počet jadier) + 1 workermi, každý s 80 až 200 MB. Asynchrónny worker drží mnoho čakajúcich požiadaviek v rámci jediného procesu.
• Node.js: jediný proces udrží tisíce čakajúcich pripojení, ale využíva len jedno jadro; režim cluster alebo PM2 spustí jeden proces na každý vCPU.
• Databáza: PostgreSQL otvára jeden proces na pripojenie a predvolene ich prijme 100. Nad niekoľko desiatok aktívnych pripojení je lepšou voľbou pooler, napríklad PgBouncer, než zvýšenie max_connections.

Trvalé pripojenia (websockety, notifikácie v reálnom čase) sa počítajú zvlášť: sú otvorené nepretržite, zaberajú málo procesora a každé niekoľko desiatok kilobajtov pamäte. Server Node.js ich udrží tisíce v niekoľkých stovkách MB.

Skutočné úzke hrdlá

V reálnej aplikácii sa server zriedka zahltí tam, kde by ste to čakali. Najčastejšie príčiny, v poradí, v akom ich hľadať:

1. Pomalý dopyt SQL: chýbajúci index zmení dopyt trvajúci 2 ms na dopyt trvajúci 2 sekundy, ktorý drží worker aj pripojenie. Na PostgreSQL ho odhalí pg_stat_statements, na MySQL log pomalých dopytov.
2. Kaskádové dopyty (problém N+1): stránka, ktorá spustí jeden dopyt na každý zobrazený riadok, ich spustí stovky.
3. Synchrónne externé volanie: platobné API alebo API umelej inteligencie, ktoré odpovie za 3 sekundy, zablokuje synchrónny worker na 3 sekundy.
4. Náročné spracovanie v rámci požiadavky: odosielanie e-mailov, zmenšovanie obrázkov, generovanie PDF, ktoré treba presunúť do frontu úloh.
5. Chýbajúca cache: stránky, ktoré sú rovnaké pre všetkých návštevníkov, sa obsluhujú z cache, statické súbory priamo z webového servera.

Overenie: záťažový test

Rádové hodnoty dajú prvú veľkosť; záťažový test dá tú skutočnú. Princíp: simulovať stále viac používateľov na kópii aplikácie a zaznamenať okamih, keď sa čas odozvy prudko zhorší.

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

Pre celý používateľský scenár (prihlásenie, prechádzanie, vyhľadávanie) opíše k6 postup v JavaScripte a zvyšuje záťaž po stupňoch:

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 kópiu, nie produkciu, a upozornite poskytovateľa hostingu, ak test mieri na server, ktorý prevádzkuje.
• Test spúšťajte z iného stroja, než je testovaný server, inak mu nástroj uberá jeho vlastné prostriedky.
• Sledujte 95. percentil času odozvy, nie priemer: práve ten zažívajú vaši najhoršie obslúžení používatelia.
• Počas testu sledujte server: htop pre procesor, free -h pre pamäť, logy pre chyby.

Keď záťaž rastie

Poradie, ktoré stojí najmenej a prinesie najviac:

1. Ukladať do cache všetko, čo sa dá (stránky, fragmenty, výsledky dopytov), a opraviť pomalé dopyty.
2. Nastaviť počet workerov podľa dostupnej pamäte a procesora.
3. Prejsť na vyššiu veľkosť: viac vCPU a pamäte, bez akejkoľvek zmeny v aplikácii.
4. Presunúť databázu na vlastný server.
5. Rozložiť aplikáciu na viacero serverov za vyvažovačom záťaže.

Prvé tri kroky pokryjú veľkú väčšinu podnikových aplikácií, webov a API: niekoľko stoviek používateľov aktívnych v rovnakom čase sa zmestí na jediný dobre nastavený server.