Hoeveel gelijktijdige gebruikers kan een VPS aan: zo rekent u het uit

Van gebruikers naar verzoeken

“Gelijktijdige gebruikers” staat voor drie verschillende grootheden, afhankelijk van wie het zegt:

• De geregistreerde accounts: ze kosten de server niets zolang ze niet inloggen.
• De gebruikers die tegelijk actief zijn: mensen die navigeren, lezen, een formulier invullen. Elk van hen stuurt af en toe een verzoek, doorgaans elke 10 tot 30 seconden, plus enkele API-aanroepen per scherm in een moderne applicatie.
• De verzoeken die in behandeling zijn: de verzoeken die de server op een gegeven moment verwerkt. Dat is de enige grootheid die processor en geheugen verbruikt.

Van de ene naar de andere gaat u met de wet van Little: het aantal lopende verzoeken is gelijk aan de doorvoer, in verzoeken per seconde, vermenigvuldigd met de gemiddelde duur van een verzoek.

Voorbeeld. 600 gebruikers die tegelijk actief zijn en elk om de 20 seconden een verzoek doen, geven 30 verzoeken per seconde. Duurt elk verzoek 100 ms, dan heeft de server gemiddeld maar 3 lopende verzoeken. De uitdaging ligt elders: in de pieken en in de trage verzoeken.

Wat een vCPU aankan

Een verzoek bezet de processor zolang het rekent: de code uitvoeren, de database bevragen, het antwoord opbouwen. Een vCPU verwerkt dus hooguit 1.000 ÷ t verzoeken per seconde, waarbij t de rekentijd van een verzoek in milliseconden is. De tijd die aan wachten opgaat (op een externe API, op een schijf) bezet de processor niet, maar wel een worker.

Met deze ordes van grootte bezetten 30 API-verzoeken per seconde met 10 ms rekentijd 30% van één vCPU. Dezelfde 30 verzoeken per seconde op WordPress-pagina’s zonder cache vragen 3 tot 9 vCPU. Een paginacache dient precies om een pagina van de vierde regel van de tabel naar de tweede te brengen.

Wat het geheugen aankan

Elk lopend verzoek wordt afgehandeld door een worker, en workers nemen geheugen in, of ze nu werken of niet. Vaak is het eerder het geheugen dan de processor dat bepaalt hoeveel verzoeken parallel worden verwerkt:

• PHP-FPM: één proces per lopend verzoek, 40 tot 80 MB per proces. pm.max_children legt het plafond vast: 20 processen, dat is 800 MB tot 1,6 GB.
• Python (Gunicorn, Uvicorn): de documentatie van Gunicorn raadt aan te beginnen met (2 × aantal cores) + 1 workers, van 80 tot 200 MB elk. Een asynchrone worker houdt in één enkel proces veel verzoeken in de wacht.
• Node.js: één proces houdt duizenden verbindingen in de wacht, maar gebruikt één core; de clustermodus, of PM2, start één proces per vCPU.
• De database: PostgreSQL opent één proces per verbinding en accepteert er standaard 100. Boven enkele tientallen actieve verbindingen is een connection pooler zoals PgBouncer een betere keuze dan max_connections te verhogen.

Persistente verbindingen (websockets, realtime meldingen) tellen apart: ze staan permanent open en gebruiken elk weinig processor en enkele tientallen kilobytes geheugen. Een Node.js-server houdt er duizenden vast in enkele honderden MB.

De echte knelpunten

Bij een echte applicatie raakt de server zelden verzadigd waar u het verwacht. De meest voorkomende oorzaken, in de volgorde waarin u ze opspoort:

1. Een trage SQL-query: een ontbrekende index maakt van een query van 2 ms een query van 2 seconden, die een worker en een verbinding vasthoudt. pg_stat_statements op PostgreSQL, of de slow query log van MySQL, wijst hem aan.
2. Query’s in cascade (het N+1-probleem): een pagina die één query per getoonde regel uitvoert, voert er honderden uit.
3. Een synchrone externe aanroep: een betaal- of AI-API die in 3 seconden antwoordt, blokkeert een synchrone worker 3 seconden lang.
4. Zwaar werk binnen het verzoek: e-mails versturen, afbeeldingen verkleinen, pdf’s genereren, allemaal werk voor een takenwachtrij.
5. Het ontbreken van een cache: pagina’s die voor alle bezoekers gelijk zijn, horen in een cache, statische bestanden bij de webserver.

Het controleren: de loadtest

De ordes van grootte geven een eerste formaat; een loadtest geeft het echte. Het principe: steeds meer gebruikers simuleren op een kopie van de applicatie, en het moment noteren waarop de responstijd wegloopt.

wrk -t2 -c50 -d30s --latency https://staging.uw-site.com/

Voor een volledig traject (inloggen, navigeren, zoeken) beschrijft k6 een scenario in JavaScript en voert het de belasting stap voor stap op:

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

• Test een kopie, niet de productie, en laat het uw hostingprovider weten als de test gericht is op een server die hij exploiteert.
• Start de test vanaf een andere machine dan de geteste server, anders neemt het hulpmiddel de server zijn eigen resources af.
• Kijk naar het 95^e percentiel van de responstijd, niet naar het gemiddelde: dat is wat uw minst goed bediende gebruikers ervaren.
• Observeer de server tijdens de test: htop voor de processor, free -h voor het geheugen, de logs voor de fouten.

Als de belasting groeit

De volgorde die het minst kost en het meest oplevert:

1. Cachen wat gecachet kan worden (pagina’s, fragmenten, queryresultaten) en trage query’s corrigeren.
2. Het aantal workers afstemmen op het beschikbare geheugen en de beschikbare processor.
3. Overstappen naar een groter formaat: meer vCPU en geheugen, zonder iets aan de applicatie te veranderen.
4. De database op een eigen server zetten.
5. De applicatie over meerdere servers verdelen achter een load balancer.

De eerste drie stappen dekken de overgrote meerderheid van bedrijfsapplicaties, websites en API’s: enkele honderden gebruikers die tegelijk actief zijn, passen op één goed afgestelde server.