Montako samanaikaista käyttäjää VPS kestää: näin sen laskette

Käyttäjistä pyyntöihin

”Samanaikaiset käyttäjät” tarkoittaa kolmea eri suuretta sen mukaan, kuka puhuu:

• Rekisteröityneet tilit: ne eivät kuormita palvelinta lainkaan niin kauan kuin ne eivät kirjaudu sisään.
• Yhtä aikaa aktiiviset käyttäjät: henkilöt, jotka selaavat, lukevat tai täyttävät lomaketta. Kukin lähettää pyynnön aina välillä (pyyntöjen välinen aika on tyypillisesti 10 ja 30 sekunnin välillä), ja modernissa sovelluksessa jokainen näkymä tekee lisäksi muutaman rajapintakutsun.
• Käsittelyssä olevat pyynnöt: ne, joita palvelin laskee tietyllä hetkellä. Vain tämä suure kuluttaa suoritinta ja muistia.

Suureesta toiseen päästään Littlen lailla: käsittelyssä olevien pyyntöjen määrä on läpäisy (pyyntöä sekunnissa) kerrottuna pyynnön keskimääräisellä kestolla.

Esimerkki. 600 yhtä aikaa aktiivista käyttäjää, joista kukin tekee pyynnön 20 sekunnin välein, tuottaa 30 pyyntöä sekunnissa. Jos kukin pyyntö kestää 100 ms, palvelimella on käsittelyssä keskimäärin vain 3 pyyntöä. Ratkaiseva kysymys on muualla: piikeissä ja hitaissa pyynnöissä.

Mitä yksi vCPU kestää

Pyyntö varaa suorittimen laskentansa ajaksi: koodin suoritus, tietokantakysely, vastauksen muodostaminen. Yksi vCPU käsittelee siis enintään 1 000 ÷ t pyyntöä sekunnissa, missä t on yhden pyynnön laskenta-aika millisekunteina. Odottamiseen kuluva aika (ulkoinen rajapinta, levy) ei varaa suoritinta, mutta se varaa workerin.

Näillä suuruusluokilla 30 rajapintapyyntöä sekunnissa 10 ms:n laskenta-ajalla vie 30 % yhdestä vCPU:sta. Samat 30 pyyntöä sekunnissa WordPress-sivuihin ilman välimuistia vaativat 3 ja 9 vCPU:n välillä. Sivuvälimuistin tehtävä on juuri siirtää sivu taulukon neljänneltä riviltä toiselle.

Mitä muisti kestää

Jokaisen käsittelyssä olevan pyynnön hoitaa worker, ja workerit vievät muistia, tekivät ne työtä tai eivät. Usein juuri muisti, enemmän kuin suoritin, ratkaisee rinnakkain käsiteltävien pyyntöjen määrän:

• PHP-FPM: yksi prosessi käsittelyssä olevaa pyyntöä kohden, kukin 40 ja 80 MB:n välillä. pm.max_children asettaa ylärajan: 20 prosessia vie 800 MB:n ja 1,6 GB:n välillä.
• Python (Gunicorn, Uvicorn): Gunicornin dokumentaatio ehdottaa lähtökohdaksi (2 × ytimien määrä) + 1 workeria, kukin 80 ja 200 MB:n välillä. Asynkroninen worker pitää monta pyyntöä odottamassa yhden prosessin muistilla.
• Node.js: yksi prosessi pitää tuhansia yhteyksiä odottamassa, mutta se käyttää vain yhtä ydintä; cluster-tila tai PM2 käynnistää yhden prosessin vCPU:ta kohden.
• Tietokanta: PostgreSQL avaa yhden prosessin yhteyttä kohden ja hyväksyy oletuksena 100 yhteyttä. Kun aktiivisia yhteyksiä on enemmän kuin muutama kymmenen, PgBouncerin kaltainen yhteyspooli on parempi ratkaisu kuin max_connections-arvon nostaminen.

Pysyvät yhteydet (websocketit, reaaliaikaiset ilmoitukset) lasketaan erikseen: jatkuvasti avoimina ne vievät vähän suoritinta ja kukin muutamia kymmeniä kilotavuja muistia. Node.js-palvelin pitää niitä tuhansia muutamassa sadassa megatavussa.

Todelliset pullonkaulat

Todellisessa sovelluksessa palvelin ruuhkautuu harvoin siellä, missä sitä odottaa. Yleisimmät syyt siinä järjestyksessä, jossa niitä kannattaa etsiä:

1. Hidas SQL-kysely: puuttuva indeksi muuttaa 2 ms:n kyselyn 2 sekunnin kyselyksi, joka pitää workeria ja yhteyttä varattuna. PostgreSQL:n pg_stat_statements tai MySQL:n hitaiden kyselyjen loki osoittaa sen.
2. Ketjutetut kyselyt (N+1-ongelma): sivu, joka tekee yhden kyselyn jokaista näytettyä riviä kohden, tekee niitä satoja.
3. Synkroninen ulkoinen kutsu: maksu- tai tekoälyrajapinta, joka vastaa 3 sekunnissa, pitää synkronisen workerin varattuna 3 sekuntia.
4. Raskaat käsittelyt pyynnön sisällä: sähköpostien lähetys, kuvien koon muuttaminen, PDF-tiedostojen luonti, jotka kannattaa siirtää tehtäväjonoon.
5. Välimuistin puuttuminen: kaikille kävijöille samanlaiset sivut palvellaan välimuistista ja staattiset tiedostot suoraan verkkopalvelimelta.

Varmistus: kuormitustesti

Suuruusluokat antavat ensimmäisen koon; kuormitustesti antaa todellisen. Periaate: simuloidaan yhä useampia käyttäjiä sovelluksen kopiota vastaan ja kirjataan hetki, jolloin vasteaika romahtaa.

wrk -t2 -c50 -d30s --latency https://testi.sivustonne.com/

Kokonaiselle käyttöpolulle (kirjautuminen, selaus, haku) k6 kuvaa skenaarion JavaScriptillä ja kasvattaa kuormaa porrastetusti:

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

• Testatkaa kopiota, ei tuotantoa, ja ilmoittakaa palveluntarjoajallenne, jos testi kohdistuu sen ylläpitämään palvelimeen.
• Ajakaa testi toiselta koneelta kuin testattavalta palvelimelta, muuten työkalu vie palvelimen omia resursseja.
• Katsokaa vasteajan 95. persentiiliä, ei keskiarvoa: se kertoo, mitä heikoimmin palvellut käyttäjänne kokevat.
• Seuratkaa palvelinta testin aikana: htop suorittimelle, free -h muistille ja lokit virheille.

Kun kuorma kasvaa

Järjestys, joka vaatii vähiten työtä ja tuottaa eniten:

1. Viekää välimuistiin kaikki, mikä sinne sopii (sivut, sivun osat, kyselyjen tulokset), ja korjatkaa hitaat kyselyt.
2. Säätäkää workereiden määrä käytettävissä olevan muistin ja suorittimen mukaan.
3. Siirtykää suurempaan kokoon: enemmän vCPU:ita ja muistia ilman muutoksia sovellukseen.
4. Siirtäkää tietokanta omalle palvelimelleen.
5. Jakakaa sovellus useille palvelimille kuormantasaajan taakse.

Kolme ensimmäistä vaihetta kattavat valtaosan liiketoimintasovelluksista, sivustoista ja rajapinnoista: useita satoja yhtä aikaa aktiivisia käyttäjiä mahtuu yhdelle hyvin säädetylle palvelimelle.