Kiek vartotojų vienu metu atlaiko VPS: kaip tai apskaičiuoti

Nuo vartotojų prie užklausų

„Vienu metu prisijungę vartotojai“ reiškia tris skirtingus dydžius, priklausomai nuo to, kas kalba:

• Užsiregistravusios paskyros: jos neapkrauna serverio, kol neprisijungia.
• Tuo pačiu metu aktyvūs vartotojai: žmonės, kurie naršo, skaito, pildo formą. Kiekvienas retkarčiais siunčia užklausą: paprastai tarp dviejų užklausų praeina nuo 10 iki 30 sekundžių, o šiuolaikinėje programoje dar prisideda keli API iškvietimai kiekviename ekrane.
• Apdorojamos užklausos: tos, kurias serveris skaičiuoja konkrečiu momentu. Tik šis dydis vartoja procesorių ir atmintį.

Iš vieno dydžio į kitą pereinama pagal Little dėsnį: vykdomų užklausų skaičius lygus srautui, išreikštam užklausomis per sekundę, padaugintam iš vidutinės užklausos trukmės.

Pavyzdys. 600 vienu metu aktyvių vartotojų, kurių kiekvienas užklausą siunčia kas 20 sekundžių, sudaro 30 užklausų per sekundę. Jei kiekviena užklausa trunka 100 ms, serveris vidutiniškai vienu metu apdoroja tik 3 užklausas. Tikrasis iššūkis slypi kitur: pikuose ir lėtose užklausose.

Ką atlaiko vienas vCPU

Užklausa užima procesorių tol, kol skaičiuojama: vykdomas kodas, užklausiama duomenų bazė, kuriamas atsakymas. Todėl vienas vCPU apdoroja ne daugiau kaip 1 000 ÷ t užklausų per sekundę, kur t yra vienos užklausos skaičiavimo laikas milisekundėmis. Laukimo laikas (išorinė API, diskas) procesoriaus neužima, bet užima darbinį procesą.

Pagal šiuos dydžius 30 API užklausų per sekundę po 10 ms skaičiavimo užima 30 % vieno vCPU. Tos pačios 30 užklausų per sekundę WordPress puslapiams be podėlio reikalauja nuo 3 iki 9 vCPU. Puslapių podėlis kaip tik ir skirtas tam, kad puslapis iš ketvirtos lentelės eilutės pereitų į antrą.

Ką atlaiko atmintis

Kiekvieną vykdomą užklausą apdoroja darbinis procesas, o darbiniai procesai užima atmintį, nesvarbu, dirba jie ar ne. Dažnai būtent atmintis, labiau nei procesorius, lemia, kiek užklausų apdorojama lygiagrečiai:

• PHP-FPM: vienas procesas kiekvienai vykdomai užklausai, kiekvienas nuo 40 iki 80 MB. pm.max_children nustato viršutinę ribą: 20 procesų reiškia nuo 800 MB iki 1,6 GB.
• Python (Gunicorn, Uvicorn): Gunicorn dokumentacija siūlo pradėti nuo (2 × branduolių skaičius) + 1 darbinių procesų, kurių kiekvienas užima nuo 80 iki 200 MB. Asinchroninis darbinis procesas laiko daug laukiančių užklausų, užimdamas vieno proceso atmintį.
• Node.js: vienas procesas laiko tūkstančius laukiančių jungčių, bet naudoja tik vieną branduolį; cluster režimas arba PM2 paleidžia po vieną procesą kiekvienam vCPU.
• Duomenų bazė: PostgreSQL kiekvienai jungčiai atidaro procesą ir pagal numatytuosius nustatymus priima 100 jungčių. Kai aktyvių jungčių daugiau nei kelios dešimtys, jungčių telkimo įrankis, pavyzdžiui, PgBouncer, tinka geriau nei max_connections didinimas.

Nuolatinės jungtys (websockets, realiojo laiko pranešimai) skaičiuojamos atskirai: nuolat atviros, jos užima mažai procesoriaus ir po kelias dešimtis kilobaitų atminties. Node.js serveris jų išlaiko tūkstančius per kelis šimtus MB.

Tikrosios siaurosios vietos

Realioje programoje serveris retai perkraunamas ten, kur to tikimasi. Dažniausios priežastys, ta tvarka, kuria verta jų ieškoti:

1. Lėta SQL užklausa: trūkstamas indeksas 2 ms užklausą paverčia 2 sekundžių užklausa, kuri užlaiko darbinį procesą ir jungtį. PostgreSQL pg_stat_statements arba MySQL lėtų užklausų žurnalas ją parodo.
2. Užklausų kaskados (N+1 problema): puslapis, kuris kiekvienai rodomai eilutei paleidžia po užklausą, jų paleidžia šimtus.
3. Sinchroninis išorinis iškvietimas: mokėjimų ar DI API, atsakanti per 3 sekundes, 3 sekundėms užblokuoja sinchroninį darbinį procesą.
4. Sunkūs procesai užklausos viduje: el. laiškų siuntimas, vaizdų dydžio keitimas, PDF generavimas, kuriuos verta perkelti į užduočių eilę.
5. Podėlio nebuvimas: visiems lankytojams vienodi puslapiai pateikiami iš podėlio, statiniai failai iš žiniatinklio serverio.

Patikrinti: apkrovos testas

Orientaciniai dydžiai duoda pirmąjį dydį; apkrovos testas duoda tikrąjį. Principas: programos kopijoje imituoti vis daugiau vartotojų ir užfiksuoti momentą, kai atsako laikas staiga pablogėja.

wrk -t2 -c50 -d30s --latency https://testavimas.jusu-svetaine.com/

Visam naudojimo scenarijui (prisijungimas, naršymas, paieška) k6 aprašo scenarijų JavaScript kalba ir didina apkrovą pakopomis:

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

• Testuokite kopiją, o ne gamybinę aplinką, ir įspėkite hostingo teikėją, jei testas nukreiptas į jo eksploatuojamą serverį.
• Testą paleiskite iš kitos mašinos, ne iš testuojamo serverio, antraip įrankis atims jo paties išteklius.
• Žiūrėkite atsako laiko 95-ąjį procentilį, o ne vidurkį: tai patiria prasčiausiai aptarnaujami jūsų vartotojai.
• Stebėkite serverį testo metu: htop procesoriui, free -h atminčiai, žurnalus klaidoms.

Kai apkrova auga

Tvarka, kuri reikalauja mažiausiai pastangų ir duoda daugiausia naudos:

1. Įdėti į podėlį tai, ką galima (puslapius, fragmentus, užklausų rezultatus), ir pataisyti lėtas užklausas.
2. Darbinių procesų skaičių suderinti su turima atmintimi ir procesoriumi.
3. Pereiti prie didesnio dydžio: daugiau vCPU ir atminties, nieko nekeičiant programoje.
4. Duomenų bazę perkelti į atskirą serverį.
5. Programą paskirstyti keliems serveriams už apkrovos balansavimo įrenginio.

Pirmieji trys žingsniai tinka didžiajai daugumai verslo valdymo programų, svetainių ir API: keli šimtai vienu metu aktyvių vartotojų telpa viename gerai sureguliuotame serveryje.