Mitu samaaegset kasutajat VPS talub: kuidas seda arvutada

Kasutajatest päringuteni

«Samaaegsed kasutajad» tähistab olenevalt rääkijast kolme eri suurust:

• Registreeritud kontod: need ei koorma serverit, kuni keegi neist sisse ei logi.
• Korraga aktiivsed kasutajad: inimesed, kes sirvivad, loevad, täidavad vormi. Igaüks saadab aeg-ajalt päringu, tavaliselt iga 10 kuni 30 sekundi järel, lisaks kaasaegses rakenduses mõni API-kutse ekraani kohta.
• Töötlemisel olevad päringud: need, mida server antud hetkel arvutab. See on ainus suurus, mis tarbib protsessorit ja mälu.

Ühelt teisele liigutakse Little'i seaduse abil: käimasolevate päringute arv võrdub läbilaskevõimega päringutes sekundis, korrutatud päringu keskmise kestusega.

Näide. 600 korraga aktiivset kasutajat, kellest igaüks käivitab päringu iga 20 sekundi järel, teevad 30 päringut sekundis. Kui iga päring kestab 100 ms, on serveril keskmiselt ainult 3 käimasolevat päringut. Tegelik küsimus on mujal: tippudes ja aeglastes päringutes.

Mida üks vCPU talub

Päring hõivab protsessorit oma arvutuse ajaks: koodi täitmine, andmebaasi pärimine, vastuse koostamine. Üks vCPU töötleb seega kõige rohkem 1 000 ÷ t päringut sekundis, kus t on päringu arvutusaeg millisekundites. Ootamisele kuluv aeg (väline API, ketas) protsessorit ei hõiva, kuid hõivab workeri.

Nende suurusjärkude järgi hõivavad 30 API-päringut sekundis 10 ms arvutusajaga 30 % ühest vCPU-st. Samad 30 päringut sekundis vahemäluta WordPressi lehtedel nõuavad 3 kuni 9 vCPU-d. Lehevahemälu ülesanne ongi viia leht tabeli neljandalt realt teisele.

Mida mälu talub

Iga käimasolevat päringut käsitleb worker ja workerid hõivavad mälu, olgu nad tööga hõivatud või mitte. Sageli määrab paralleelselt töödeldavate päringute arvu pigem mälu kui protsessor:

• PHP-FPM: üks protsess iga käimasoleva päringu kohta, igaüks 40 kuni 80 MB. pm.max_children seab ülempiiri: 20 protsessi teeb 800 MB kuni 1,6 GB.
• Python (Gunicorn, Uvicorn): Gunicorni dokumentatsioon soovitab alustada (2 × tuumade arv) + 1 workerist, igaüks 80 kuni 200 MB. Asünkroonne worker hoiab paljusid päringuid ootel ühe protsessi mälukuluga.
• Node.js: üks protsess hoiab ootel tuhandeid ühendusi, kuid kasutab ainult ühte tuuma; klastrirežiim või PM2 käivitab ühe protsessi vCPU kohta.
• Andmebaas: PostgreSQL avab iga ühenduse jaoks protsessi ja lubab vaikimisi 100 ühendust. Kui aktiivseid ühendusi on üle mõnekümne, on ühenduste koondaja nagu PgBouncer parem lahendus kui max_connections tõstmine.

Püsiühendusi (websocketid, reaalajas teavitused) arvestatakse eraldi: pidevalt avatuna hõivavad need vähe protsessorit ja igaüks mõnikümmend kilobaiti mälu. Node.js-server hoiab neid tuhandeid mõnesaja megabaidi sees.

Tegelikud kitsaskohad

Päris rakenduses küllastub server harva seal, kus seda oodatakse. Kõige sagedasemad põhjused, järjekorras, milles neid otsida:

1. Aeglane SQL-päring: puuduv indeks muudab 2 ms päringu 2-sekundiliseks ja see hoiab kinni workeri ning ühenduse. PostgreSQL-is näitab selle pg_stat_statements, MySQL-is aeglaste päringute logi.
2. Kaskaadpäringud (N+1 probleem): leht, mis käivitab iga kuvatava rea kohta ühe päringu, käivitab neid sadu.
3. Sünkroonne väliskutse: makse- või AI-API, mis vastab 3 sekundiga, blokeerib sünkroonse workeri 3 sekundiks.
4. Rasked töötlused päringu sees: e-kirjade saatmine, piltide suuruse muutmine, PDF-ide genereerimine; need kuuluvad tööjärjekorda.
5. Vahemälu puudumine: kõigile külastajatele ühesugused lehed serveeritakse vahemälust, staatilised failid veebiserverist.

Kontroll: koormustest

Suurusjärgud annavad esimese suuruse; koormustest annab tegeliku. Põhimõte: simuleerida rakenduse koopial üha rohkem kasutajaid ja märkida hetk, mil vastamisaeg järsult halveneb.

wrk -t2 -c50 -d30s --latency https://preprod.teie-sait.com/

Tervikliku kasutajateekonna jaoks (sisselogimine, sirvimine, otsing) kirjeldab k6 stsenaariumi JavaScriptis ja tõstab koormust astmeti:

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

• Testige koopiat, mitte tootmiskeskkonda, ja teavitage oma majutajat, kui test on suunatud tema käitatavale serverile.
• Käivitage test teisest masinast, mitte testitavast serverist, muidu võtab tööriist tema enda ressursse.
• Vaadake vastamisaja 95. protsentiili, mitte keskmist: seda kogevad teie kõige halvemini teenindatud kasutajad.
• Jälgige serverit testi ajal: htop protsessori jaoks, free -h mälu jaoks, logid vigade jaoks.

Kui koormus kasvab

Järjekord, mis nõuab kõige vähem ja annab kõige rohkem:

1. Pange vahemällu kõik, mida saab (lehed, fragmendid, päringute tulemused), ja parandage aeglased päringud.
2. Seadistage workerite arv vastavalt saadaolevale mälule ja protsessorile.
3. Minge üle suuremale suurusele: rohkem vCPU-sid ja mälu, rakenduses midagi muutmata.
4. Paigutage andmebaas oma serverisse.
5. Jaotage rakendus mitmele serverile koormusjaoturi taha.

Esimesed kolm sammu katavad valdava enamiku äritarkvarast, saitidest ja API-dest: mitusada korraga aktiivset kasutajat mahub ühte hästi häälestatud serverisse.