Koliko istovremenih korisnika podnosi VPS: napravite izračun

Od korisnika do zahtjeva

„Istovremeni korisnici” označava tri različite veličine, ovisno o tome tko govori:

• Registrirani računi: poslužitelj ništa ne opterećuju dok se ne prijave.
• Korisnici aktivni u isto vrijeme: osobe koje pregledavaju, čitaju, ispunjavaju obrazac. Svaka od njih s vremena na vrijeme pošalje zahtjev, obično svakih 10 do 30 sekundi, plus nekoliko API poziva po zaslonu u modernoj aplikaciji.
• Zahtjevi u obradi: oni koje poslužitelj u danom trenutku izračunava. To je jedina veličina koja troši procesor i memoriju.

Od jedne do druge dolazi se Littleovim zakonom: broj zahtjeva u obradi jednak je protoku, u zahtjevima u sekundi, pomnoženom s prosječnim trajanjem zahtjeva.

Primjer. 600 korisnika aktivnih u isto vrijeme, od kojih svaki pokrene zahtjev svakih 20 sekundi, čini 30 zahtjeva u sekundi. Ako svaki zahtjev traje 100 ms, poslužitelj u prosjeku ima samo 3 zahtjeva u obradi. Pravi je izazov drugdje: u vrhovima opterećenja i u sporim zahtjevima.

Koliko podnosi jedan vCPU

Zahtjev zauzima procesor dok traje njegov izračun: izvršavanje koda, upit bazi, izrada odgovora. Jedan vCPU stoga obrađuje najviše 1 000 ÷ t zahtjeva u sekundi, gdje je t vrijeme izračuna zahtjeva u milisekundama. Vrijeme provedeno u čekanju (vanjski API, disk) ne zauzima procesor, ali zauzima worker.

Uz ove redove veličine, 30 API zahtjeva u sekundi uz 10 ms izračuna zauzima 30 % jednog jedinog vCPU-a. Istih 30 zahtjeva u sekundi na WordPress stranicama bez predmemorije traži 3 do 9 vCPU-a. Predmemorija stranica služi upravo tome da stranicu prebaci iz četvrtog retka tablice u drugi.

Koliko podnosi memorija

Svaki zahtjev u obradi preuzima worker, a workeri zauzimaju memoriju, radili ili ne. Često memorija, više nego procesor, određuje broj zahtjeva koji se obrađuju usporedno:

• PHP-FPM: jedan proces po zahtjevu u obradi, svaki 40 do 80 MB. pm.max_children određuje gornju granicu: 20 procesa znači 800 MB do 1,6 GB.
• Python (Gunicorn, Uvicorn): dokumentacija Gunicorna predlaže da se krene od (2 × broj jezgri) + 1 workera, svaki od 80 do 200 MB. Asinkroni worker drži mnogo zahtjeva na čekanju, a zauzima koliko i jedan jedini proces.
• Node.js: jedan jedini proces drži tisuće veza na čekanju, ali koristi samo jednu jezgru; način rada cluster, ili PM2, pokreće po jedan proces za svaki vCPU.
• Baza podataka: PostgreSQL otvara jedan proces po vezi i prema zadanim postavkama prihvaća njih 100. Iznad nekoliko desetaka aktivnih veza, alat za grupiranje veza poput PgBouncera bolji je izbor od povećanja parametra max_connections.

Trajne veze (websocketi, obavijesti u stvarnom vremenu) broje se zasebno: stalno otvorene, zauzimaju malo procesora i po nekoliko desetaka kilobajta memorije. Node.js poslužitelj drži ih tisuće u nekoliko stotina MB.

Prava uska grla

U stvarnoj aplikaciji poslužitelj se rijetko zaguši ondje gdje se to očekuje. Najčešći uzroci, redom kojim ih treba tražiti:

1. Spor SQL upit: indeks koji nedostaje pretvara upit od 2 ms u upit od 2 sekunde, koji zadržava worker i vezu. pg_stat_statements na PostgreSQL-u ili zapis sporih upita u MySQL-u pokazuje ga.
2. Kaskadni upiti (problem N+1): stranica koja pokreće jedan upit po prikazanom retku pokreće ih stotine.
3. Sinkroni vanjski poziv: API za plaćanje ili AI koji odgovara za 3 sekunde blokira sinkroni worker na 3 sekunde.
4. Zahtjevne obrade unutar zahtjeva: slanje e-pošte, promjena veličine slika, izrada PDF-ova, koje treba premjestiti u red zadataka.
5. Izostanak predmemorije: stranice koje su jednake za sve posjetitelje poslužuju se iz predmemorije, a statične datoteke s web poslužitelja.

Provjera: test opterećenja

Redovi veličine daju prvu procjenu veličine; test opterećenja daje stvarnu. Načelo: simulirati sve veći broj korisnika na kopiji aplikacije i zabilježiti trenutak kada vrijeme odziva naglo poraste.

wrk -t2 -c50 -d30s --latency https://test.vasa-stranica.com/

Za cijeli put korisnika (prijava, pregledavanje, pretraživanje) k6 opisuje scenarij u JavaScriptu i povećava opterećenje u koracima:

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://test.vasa-stranica.com/');
  sleep(15);
}

• Testirajte kopiju, a ne produkciju, i obavijestite pružatelja hostinga ako test cilja poslužitelj kojim on upravlja.
• Pokrenite test s drugog stroja, a ne s poslužitelja koji testirate, inače mu alat oduzima vlastite resurse.
• Gledajte 95. percentil vremena odziva, a ne prosjek: to doživljavaju vaši najlošije posluženi korisnici.
• Pratite poslužitelj tijekom testa: htop za procesor, free -h za memoriju, zapise za pogreške.

Kada opterećenje raste

Redoslijed koji traži najmanje truda, a donosi najviše:

1. Staviti u predmemoriju ono što se može (stranice, fragmente, rezultate upita) i ispraviti spore upite.
2. Uskladiti broj workera s dostupnom memorijom i procesorom.
3. Prijeći na veću veličinu: više vCPU-a i memorije, bez ikakve promjene u aplikaciji.
4. Premjestiti bazu podataka na vlastiti poslužitelj.
5. Rasporediti aplikaciju na više poslužitelja iza raspodjeljivača opterećenja (load balancer).

Prva tri koraka pokrivaju veliku većinu poslovnih aplikacija, stranica i API-ja: nekoliko stotina korisnika aktivnih u isto vrijeme radi na jednom dobro podešenom poslužitelju.