Cik vienlaicīgu lietotāju iztur VPS: kā to aprēķināt

No lietotājiem uz pieprasījumiem

«Vienlaicīgi lietotāji» apzīmē trīs dažādus lielumus atkarībā no tā, kurš runā:

• Reģistrētie konti: kamēr tie nepieslēdzas, serverim tie neko neprasa.
• Vienlaikus aktīvie lietotāji: cilvēki, kas pārlūko, lasa, aizpilda veidlapu. Katrs no laika pa laikam nosūta pieprasījumu, parasti reizi 10 līdz 30 sekundēs, plus dažus API izsaukumus katrā ekrānā mūsdienīgā lietojumprogrammā.
• Apstrādē esošie pieprasījumi: tie, ko serveris aprēķina konkrētā brīdī. Tas ir vienīgais lielums, kas patērē procesoru un atmiņu.

No viena lieluma uz otru pāriet ar Litla likumu: apstrādē esošo pieprasījumu skaits ir vienāds ar caurlaidspēju pieprasījumos sekundē, kas reizināta ar pieprasījuma vidējo ilgumu.

Piemērs. 600 vienlaikus aktīvi lietotāji, no kuriem katrs izraisa pieprasījumu reizi 20 sekundēs, rada 30 pieprasījumus sekundē. Ja katrs pieprasījums ilgst 100 ms, serverim vidēji apstrādē ir tikai 3 pieprasījumi. Īstais izaicinājums ir citur: maksimumos un lēnajos pieprasījumos.

Ko iztur viens vCPU

Pieprasījums aizņem procesoru, kamēr tas skaitļo: izpilda kodu, vaicā datubāzi, veido atbildi. Tāpēc viens vCPU apstrādā ne vairāk kā 1000 ÷ t pieprasījumu sekundē, kur t ir viena pieprasījuma skaitļošanas laiks milisekundēs. Gaidīšanas laiks (ārējs API, disks) procesoru neaizņem, bet aizņem darba procesu.

Ar šiem lielumiem 30 API pieprasījumi sekundē ar 10 ms skaitļošanas aizņem 30 % no viena vCPU. Tie paši 30 pieprasījumi sekundē uz WordPress lapām bez kešatmiņas prasa 3 līdz 9 vCPU. Lapu kešatmiņa kalpo tieši tam, lai lapu pārceltu no tabulas ceturtās rindas uz otro.

Ko iztur atmiņa

Katru apstrādē esošu pieprasījumu apkalpo darba process (worker), un darba procesi aizņem atmiņu neatkarīgi no tā, vai tie strādā. Bieži tieši atmiņa, vairāk nekā procesors, nosaka paralēli apstrādājamo pieprasījumu skaitu:

• PHP-FPM: viens process uz katru apstrādē esošu pieprasījumu, katrs 40 līdz 80 MB. pm.max_children nosaka griestus: 20 procesi ir 800 MB līdz 1,6 GB.
• Python (Gunicorn, Uvicorn): Gunicorn dokumentācija iesaka sākt ar (2 × kodolu skaits) + 1 darba procesiem, katrs 80 līdz 200 MB. Asinhrons darba process tur gaidīšanā daudz pieprasījumu, aizņemot tikai viena procesa atmiņu.
• Node.js: viens process tur gaidīšanā tūkstošiem savienojumu, bet izmanto tikai vienu kodolu; klastera režīms jeb PM2 palaiž vienu procesu uz katru vCPU.
• Datubāze: PostgreSQL atver vienu procesu uz katru savienojumu un pēc noklusējuma pieņem 100. Ja aktīvo savienojumu ir vairāk par dažiem desmitiem, savienojumu apvienotājs, piemēram, PgBouncer, ir labāks risinājums nekā max_connections palielināšana.

Pastāvīgos savienojumus (websockets, reāllaika paziņojumi) skaita atsevišķi: tie ir atvērti visu laiku, patērē maz procesora un katrs dažus desmitus kilobaitu atmiņas. Node.js serveris tur tūkstošiem tādu dažos simtos MB.

Īstās šaurās vietas

Reālā lietojumprogrammā serveris reti sasniedz robežu tur, kur to gaida. Biežākie cēloņi tādā secībā, kādā tos meklēt:

1. Lēns SQL vaicājums: trūkstošs indekss pārvērš 2 ms vaicājumu 2 sekunžu vaicājumā, kas aiztur darba procesu un savienojumu. PostgreSQL vidē to atklāj pg_stat_statements, MySQL vidē lēno vaicājumu žurnāls.
2. Kaskādes vaicājumi (N+1 problēma): lapa, kas palaiž vienu vaicājumu katrai attēlotajai rindai, palaiž to simtiem.
3. Sinhrons ārējs izsaukums: maksājumu vai mākslīgā intelekta API, kas atbild 3 sekundēs, bloķē sinhronu darba procesu uz 3 sekundēm.
4. Smagas darbības pieprasījuma iekšienē: e-pastu sūtīšana, attēlu izmēru maiņa, PDF ģenerēšana, kas jāpārceļ uz uzdevumu rindu.
5. Kešatmiņas trūkums: lapas, kas visiem apmeklētājiem ir vienādas, apkalpo no kešatmiņas, statiskos failus apkalpo tīmekļa serveris.

Pārbaudīt: slodzes tests

Aptuvenie lielumi dod pirmo izmēru; slodzes tests dod īsto. Princips: lietojumprogrammas kopijā simulēt arvien vairāk lietotāju un konstatēt brīdi, kad atbildes laiks strauji pasliktinās.

wrk -t2 -c50 -d30s --latency https://preprod.jusu-vietne.com/

Pilnam lietotāja ceļam (pieslēgšanās, pārlūkošana, meklēšana) k6 apraksta scenāriju JavaScript valodā un palielina slodzi pakāpeniski:

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

• Testējiet kopiju, nevis produkciju, un brīdiniet savu hostinga pakalpojumu sniedzēju, ja tests vērsts pret serveri, ko tas uztur.
• Palaidiet testu no citas mašīnas, nevis no testējamā servera, citādi rīks atņem serverim tā paša resursus.
• Skatieties atbildes laika 95. procentili, nevis vidējo: to piedzīvo jūsu vissliktāk apkalpotie lietotāji.
• Vērojiet serveri testa laikā: htop procesoram, free -h atmiņai, žurnālus kļūdām.

Kad slodze pieaug

Secība, kas prasa vismazāk un dod visvairāk:

1. Kešot to, ko var (lapas, fragmentus, vaicājumu rezultātus), un izlabot lēnos vaicājumus.
2. Noregulēt darba procesu skaitu atbilstoši pieejamajai atmiņai un procesoram.
3. Pāriet uz lielāku izmēru: vairāk vCPU un atmiņas, neko nemainot lietojumprogrammā.
4. Novietot datubāzi atsevišķā serverī.
5. Sadalīt lietojumprogrammu starp vairākiem serveriem aiz slodzes līdzsvarotāja.

Pirmie trīs soļi sedz lielāko daļu biznesa lietojumprogrammu, vietņu un API: vairāki simti vienlaikus aktīvu lietotāju ietilpst vienā labi noregulētā serverī.