Hány egyidejű felhasználót bír el egy VPS: a számítás elvégzése

A felhasználóktól a kérésekig

Az „egyidejű felhasználók” három különböző mennyiséget jelent attól függően, ki beszél:

• A regisztrált fiókok: semmibe sem kerülnek a szervernek, amíg be nem jelentkeznek.
• Az egyszerre aktív felhasználók: böngésző, olvasó, űrlapot kitöltő emberek. Mindegyikük időnként küld egy kérést, jellemzően 10 és 30 másodperc közötti időközönként, egy modern alkalmazásban pedig képernyőnként még néhány API-hívást.
• A feldolgozás alatt álló kérések: azok, amelyeken a szerver egy adott pillanatban dolgozik. Ez az egyetlen mennyiség, amely processzort és memóriát fogyaszt.

Az egyikről a másikra Little törvénye segítségével lehet áttérni: a folyamatban lévő kérések száma egyenlő az átbocsátással (kérés másodpercenként) szorozva egy kérés átlagos időtartamával.

Példa. 600 egyszerre aktív felhasználó, akik mindegyike 20 másodpercenként indít egy kérést, másodpercenként 30 kérést jelent. Ha minden kérés 100 ms-ig tart, a szerveren átlagosan csak 3 kérés van folyamatban. A tét máshol van: a csúcsokban és a lassú kérésekben.

Mennyit bír egy vCPU

Egy kérés a számítás idejére foglalja a processzort: a kód futtatása, az adatbázis lekérdezése, a válasz összeállítása. Egy vCPU így legfeljebb 1000 ÷ t kérést dolgoz fel másodpercenként, ahol t egy kérés számítási ideje ezredmásodpercben. A várakozással töltött idő (egy külső API-ra, a lemezre) nem foglalja a processzort, de egy workert igen.

Ezekkel a nagyságrendekkel másodpercenként 30 API-kérés 10 ms számítási idővel egyetlen vCPU 30%-át foglalja le. Ugyanez a másodpercenkénti 30 kérés gyorsítótár nélküli WordPress-oldalakon 3 és 9 közötti vCPU-t igényel. Az oldalgyorsítótár éppen arra szolgál, hogy egy oldalt a táblázat negyedik sorából a második sorába vigyen át.

Mennyit bír a memória

Minden folyamatban lévő kérést egy worker kezel, a workerek pedig memóriát foglalnak, akár dolgoznak, akár nem. Gyakran a memória, és nem a processzor határozza meg a párhuzamosan feldolgozott kérések számát:

• PHP-FPM: minden folyamatban lévő kérésre egy folyamat, egyenként 40 és 80 MB között. A pm.max_children adja a plafont: 20 folyamat 800 MB és 1,6 GB között foglal.
• Python (Gunicorn, Uvicorn): a Gunicorn dokumentációja azt javasolja, hogy (2 × magok száma) + 1 workerből induljon ki, egyenként 80 és 200 MB között. Egy aszinkron worker egyetlen folyamat árán sok várakozó kérést tart.
• Node.js: egyetlen folyamat több ezer várakozó kapcsolatot tart, de csak egy magot használ; a cluster mód vagy a PM2 vCPU-nként egy folyamatot indít.
• Az adatbázis: a PostgreSQL kapcsolatonként egy folyamatot nyit, és alapértelmezés szerint 100 kapcsolatot fogad. Néhány tucat aktív kapcsolat felett egy kapcsolatkészlet-kezelő, például a PgBouncer jobb megoldás, mint a max_connections emelése.

Az állandó kapcsolatokat (websocketek, valós idejű értesítések) külön kell számolni: folyamatosan nyitva vannak, kevés processzort és egyenként néhány tíz kilobájt memóriát foglalnak. Egy Node.js-szerver több ezret is elbír belőlük néhány száz MB-ban.

A valódi szűk keresztmetszetek

Egy valós alkalmazásban a szerver ritkán ott telítődik, ahol várnánk. A leggyakoribb okok, abban a sorrendben, ahogyan keresni érdemes őket:

1. Egy lassú SQL-lekérdezés: egy hiányzó index egy 2 ms-os lekérdezést 2 másodperces lekérdezéssé alakít, amely lefoglal egy workert és egy kapcsolatot. PostgreSQL-en a pg_stat_statements, MySQL-en a lassú lekérdezések naplója mutat rá.
2. A lépcsőzetes lekérdezések (az N+1 probléma): egy oldal, amely minden megjelenített sorhoz külön lekérdezést indít, több százat indít.
3. Egy szinkron külső hívás: egy 3 másodperc alatt válaszoló fizetési API vagy MI-szolgáltatás 3 másodpercre blokkol egy szinkron workert.
4. Nehéz feldolgozás a kérésen belül: e-mail-küldés, képek átméretezése, PDF-generálás, amelyeket feladatsorba érdemes áthelyezni.
5. A gyorsítótár hiánya: a minden látogató számára azonos oldalakat gyorsítótárból, a statikus fájlokat a webszerverről érdemes kiszolgálni.

Az ellenőrzés: a terheléses teszt

A nagyságrendek egy első méretet adnak; a terheléses teszt a valódit. Az elv: egyre több felhasználót szimulálni az alkalmazás egy másolatán, és feljegyezni azt a pontot, ahol a válaszidő hirtelen megugrik.

wrk -t2 -c50 -d30s --latency https://staging.sajat-webhely.com/

Egy teljes felhasználói útvonalhoz (bejelentkezés, böngészés, keresés) a k6 JavaScriptben ír le egy forgatókönyvet, és fokozatosan emeli a terhelést:

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://staging.sajat-webhely.com/');
  sleep(15);
}

• Egy másolatot teszteljen, ne az éles környezetet, és értesítse a tárhelyszolgáltatóját, ha a teszt egy általa üzemeltetett szervert céloz.
• A tesztet egy másik gépről indítsa, ne a tesztelt szerverről, különben az eszköz a szerver saját erőforrásait használja el.
• A válaszidő 95. percentilisét nézze, ne az átlagot: ezt tapasztalják a legkevésbé jól kiszolgált felhasználói.
• Figyelje a szervert a teszt alatt: htop a processzorhoz, free -h a memóriához, a naplók a hibákhoz.

Amikor nő a terhelés

A sorrend, amely a legkevesebbe kerül és a legtöbbet hozza:

1. Gyorsítótárazza, amit lehet (oldalak, oldalrészletek, lekérdezések eredményei), és javítsa a lassú lekérdezéseket.
2. Hangolja a workerek számát a rendelkezésre álló memóriához és processzorhoz.
3. Váltson nagyobb méretre: több vCPU és memória, az alkalmazás módosítása nélkül.
4. Helyezze az adatbázist saját szerverre.
5. Ossza el az alkalmazást több szerver között egy terheléselosztó mögött.

Az első három lépés lefedi az ügyviteli alkalmazások, weboldalak és API-k túlnyomó többségét: több száz egyszerre aktív felhasználó elfér egyetlen jól hangolt szerveren.