Hvor mange samtidige brugere kan en VPS klare: sådan regner du

Fra brugere til forespørgsler

«Samtidige brugere» betegner tre forskellige størrelser, alt efter hvem der taler:

• De registrerede konti: de koster ikke serveren noget, så længe de ikke logger ind.
• De brugere, der er aktive på samme tid: personer, der navigerer, læser, udfylder en formular. Hver af dem sender en forespørgsel en gang imellem, typisk hvert 10. til 30. sekund, plus nogle API-kald pr. skærmbillede i en moderne applikation.
• De forespørgsler, der er under behandling: dem, serveren beregner på et givet tidspunkt. Det er den eneste størrelse, der bruger processor og hukommelse.

Man går fra den ene til den anden med Littles lov: antallet af igangværende forespørgsler er lig med gennemstrømningen i forespørgsler pr. sekund ganget med den gennemsnitlige varighed af en forespørgsel.

Eksempel. 600 brugere, der er aktive på samme tid og hver udløser en forespørgsel hvert 20. sekund, giver 30 forespørgsler i sekundet. Varer hver forespørgsel 100 ms, har serveren i gennemsnit kun 3 forespørgsler i gang. Udfordringen ligger et andet sted: i spidsbelastningerne og i de langsomme forespørgsler.

Det, en vCPU kan klare

En forespørgsel optager processoren, så længe den beregnes: koden kører, databasen forespørges, svaret bygges. En vCPU behandler derfor højst 1.000 ÷ t forespørgsler i sekundet, hvor t er en forespørgsels beregningstid i millisekunder. Den tid, der går med at vente (på et eksternt API, en disk), optager ikke processoren, men den optager en worker.

Med disse størrelsesordener optager 30 API-forespørgsler i sekundet med 10 ms beregning 30 % af en enkelt vCPU. De samme 30 forespørgsler i sekundet på WordPress-sider uden cache kræver 3 til 9 vCPU. Sidecachen er netop til for at flytte en side fra tabellens fjerde linje til den anden.

Det, hukommelsen kan klare

Hver igangværende forespørgsel håndteres af en worker, og workers optager hukommelse, hvad enten de arbejder eller ej. Det er ofte hukommelsen, mere end processoren, der bestemmer, hvor mange forespørgsler der behandles parallelt:

• PHP-FPM: én proces pr. igangværende forespørgsel, 40 til 80 MB hver. pm.max_children sætter loftet: 20 processer svarer til 800 MB til 1,6 GB.
• Python (Gunicorn, Uvicorn): Gunicorns dokumentation foreslår at starte med (2 × antal kerner) + 1 workers på 80 til 200 MB hver. En asynkron worker holder mange forespørgsler i venteposition med forbruget fra én enkelt proces.
• Node.js: en enkelt proces holder tusindvis af forbindelser i venteposition, men den bruger kun én kerne; cluster-tilstand eller PM2 starter én proces pr. vCPU.
• Databasen: PostgreSQL åbner én proces pr. forbindelse og accepterer 100 som standard. Ud over nogle titals aktive forbindelser er en connection pooler som PgBouncer bedre end at hæve max_connections.

Vedvarende forbindelser (websockets, notifikationer i realtid) tælles for sig: de er åbne hele tiden og bruger lidt processor og nogle titals kilobyte hukommelse hver. En Node.js-server kan klare tusindvis af dem på nogle hundrede MB.

De reelle flaskehalse

I en rigtig applikation bliver serveren sjældent overbelastet dér, hvor man venter det. De hyppigste årsager, i den rækkefølge du skal lede efter dem:

1. En langsom SQL-forespørgsel: et manglende indeks forvandler en forespørgsel på 2 ms til en på 2 sekunder, som holder en worker og en forbindelse fast. pg_stat_statements i PostgreSQL eller MySQL's log over langsomme forespørgsler peger den ud.
2. Forespørgsler i kaskade (N+1-problemet): en side, der sender én forespørgsel pr. vist linje, sender hundredvis.
3. Et synkront eksternt kald: et betalings- eller AI-API, der svarer på 3 sekunder, blokerer en synkron worker i 3 sekunder.
4. Tunge behandlinger i selve forespørgslen: afsendelse af e-mails, skalering af billeder, generering af PDF'er, som hører hjemme i en opgavekø.
5. Manglende cache: sider, der er ens for alle besøgende, leveres fra en cache, statiske filer fra webserveren.

Kontrollér det: belastningstesten

Størrelsesordenerne giver en første størrelse; en belastningstest giver den rigtige. Princippet: simulér flere og flere brugere på en kopi af applikationen, og notér det øjeblik, hvor svartiden knækker.

wrk -t2 -c50 -d30s --latency https://staging.din-hjemmeside.com/

Til et komplet forløb (login, navigation, søgning) beskriver k6 et scenarie i JavaScript og øger belastningen trinvis:

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://staging.din-hjemmeside.com/');
  sleep(15);
}

• Test en kopi, ikke produktionen, og giv din hostingudbyder besked, hvis testen rammer en server, som udbyderen driver.
• Kør testen fra en anden maskine end den server, der testes, ellers tager værktøjet af serverens egne ressourcer.
• Se på 95. percentil af svartiden, ikke på gennemsnittet: det er det, dine dårligst betjente brugere oplever.
• Hold øje med serveren under testen: htop for processoren, free -h for hukommelsen, logfilerne for fejl.

Når belastningen vokser

Den rækkefølge, der koster mindst og giver mest:

1. Cache det, der kan caches (sider, fragmenter, forespørgselsresultater), og ret de langsomme forespørgsler.
2. Indstil antallet af workers efter den tilgængelige hukommelse og processorkraft.
3. Skift til en større størrelse: flere vCPU og mere hukommelse, uden at ændre noget i applikationen.
4. Flyt databasen over på sin egen server.
5. Fordel applikationen på flere servere bag en load balancer.

De tre første trin dækker langt de fleste forretningsapplikationer, hjemmesider og API'er: flere hundrede brugere, der er aktive på samme tid, kan klares af en enkelt velindstillet server.