Koliko sočasnih uporabnikov zdrži VPS: kako to izračunati

Od uporabnikov do zahtev

„Sočasni uporabniki“ pomenijo tri različne količine, odvisno od tega, kdo govori:

• Registrirani računi: strežnika ne stanejo nič, dokler se ne prijavijo.
• Hkrati aktivni uporabniki: ljudje, ki brskajo, berejo, izpolnjujejo obrazec. Vsak od njih občasno pošlje zahtevo, običajno vsakih 10 do 30 sekund, v sodobni aplikaciji pa še nekaj klicev API-ja na zaslon.
• Zahteve v obdelavi: tiste, ki jih strežnik v danem trenutku računa. To je edina količina, ki porablja procesor in pomnilnik.

Od ene do druge pridemo z Littlovim zakonom: število zahtev v obdelavi je enako pretoku, v zahtevah na sekundo, pomnoženemu s povprečnim trajanjem zahteve.

Primer. 600 hkrati aktivnih uporabnikov, od katerih vsak sproži zahtevo vsakih 20 sekund, ustvari 30 zahtev na sekundo. Če vsaka zahteva traja 100 ms, ima strežnik v povprečju le 3 zahteve v obdelavi. Izziv je drugje: v konicah in v počasnih zahtevah.

Koliko zdrži en vCPU

Zahteva zaseda procesor toliko časa, kolikor traja njeno računanje: izvajanje kode, poizvedba v podatkovni zbirki, sestavljanje odgovora. En vCPU tako obdela največ 1000 ÷ t zahtev na sekundo, kjer je t čas računanja ene zahteve v milisekundah. Čas čakanja (zunanji API, disk) procesorja ne zaseda, zaseda pa delovni proces.

Po teh redih velikosti 30 zahtev API na sekundo z 10 ms računanja zasede 30 % enega samega vCPU. Enakih 30 zahtev na sekundo na straneh WordPress brez predpomnilnika zahteva od 3 do 9 vCPU. Predpomnilnik strani je namenjen prav temu, da stran iz četrte vrstice preglednice premakne v drugo.

Koliko zdrži pomnilnik

Vsako zahtevo v obdelavi prevzame delovni proces (worker), delovni procesi pa zasedajo pomnilnik, ne glede na to, ali delajo ali ne. Število vzporedno obdelanih zahtev pogosto bolj kot procesor določi prav pomnilnik:

• PHP-FPM: en proces na zahtevo v obdelavi, vsak od 40 do 80 MB. pm.max_children določi zgornjo mejo: 20 procesov pomeni od 800 MB do 1,6 GB.
• Python (Gunicorn, Uvicorn): dokumentacija Gunicorna predlaga izhodišče (2 × število jeder) + 1 delovnih procesov, vsak od 80 do 200 MB. En sam asinhroni delovni proces drži na čakanju veliko zahtev hkrati.
• Node.js: en sam proces drži na čakanju na tisoče povezav, vendar uporablja le eno jedro; način cluster ali PM2 zažene po en proces na vCPU.
• Podatkovna zbirka: PostgreSQL odpre po en proces na povezavo in jih privzeto sprejme 100. Pri več kot nekaj deset aktivnih povezavah je združevalnik povezav, kot je PgBouncer, boljša izbira od povečanja max_connections.

Trajne povezave (websocketi, obvestila v realnem času) se štejejo posebej: ker so stalno odprte, porabijo malo procesorja in vsaka nekaj deset kilobajtov pomnilnika. Strežnik Node.js jih zdrži na tisoče v nekaj sto MB.

Prava ozka grla

V resnični aplikaciji se strežnik le redko zasiti tam, kjer to pričakujemo. Najpogostejši vzroki, v vrstnem redu, v katerem jih iščete:

1. Počasna poizvedba SQL: manjkajoči indeks poizvedbo z 2 ms spremeni v poizvedbo z 2 sekundama, ki zadrži delovni proces in povezavo. pg_stat_statements v PostgreSQL ali dnevnik počasnih poizvedb v MySQL jo pokaže.
2. Kaskadne poizvedbe (problem N+1): stran, ki sproži eno poizvedbo za vsako prikazano vrstico, jih sproži na stotine.
3. Sinhroni zunanji klic: API za plačila ali umetno inteligenco, ki odgovori v 3 sekundah, sinhroni delovni proces blokira za 3 sekunde.
4. Zahtevne obdelave znotraj zahteve: pošiljanje e-pošte, spreminjanje velikosti slik, ustvarjanje PDF, ki jih prestavite v čakalno vrsto opravil.
5. Odsotnost predpomnilnika: strani, enake za vse obiskovalce, se strežejo iz predpomnilnika, statične datoteke pa neposredno s spletnega strežnika.

Preverjanje: obremenitveni test

Redi velikosti dajo prvo velikost; obremenitveni test da pravo. Načelo: na kopiji aplikacije simulirate vse več uporabnikov in zabeležite trenutek, ko se odzivni čas poslabša.

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

Za celoten potek (prijava, brskanje, iskanje) k6 opiše scenarij v JavaScriptu in obremenitev povečuje postopoma:

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-stran.com/');
  sleep(15);
}

• Preizkušajte kopijo, ne produkcije, in obvestite ponudnika gostovanja, če test cilja na strežnik, ki ga upravlja on.
• Test zaženite z drugega računalnika in ne s preizkušanega strežnika, sicer mu orodje odvzame njegove lastne vire.
• Glejte 95. percentil odzivnega časa, ne povprečja: to doživljajo vaši najslabše postreženi uporabniki.
• Med testom opazujte strežnik: htop za procesor, free -h za pomnilnik, dnevnike za napake.

Ko obremenitev raste

Vrstni red, ki stane najmanj in prinese največ:

1. Predpomnite, kar je mogoče (strani, dele strani, rezultate poizvedb), in popravite počasne poizvedbe.
2. Število delovnih procesov prilagodite razpoložljivemu pomnilniku in procesorju.
3. Preidite na večjo velikost: več vCPU in pomnilnika, brez kakršne koli spremembe aplikacije.
4. Podatkovno zbirko postavite na lasten strežnik.
5. Aplikacijo porazdelite na več strežnikov za izenačevalnikom obremenitve.

Prvi trije koraki pokrijejo veliko večino poslovnih aplikacij, spletnih strani in API-jev: več sto hkrati aktivnih uporabnikov zdrži en sam dobro nastavljen strežnik.