Hur många samtidiga användare klarar en VPS? Gör beräkningen

Från användare till förfrågningar

”Samtidiga användare” betyder tre olika storheter beroende på vem som talar:

• Registrerade konton: de kostar servern ingenting så länge de inte loggar in.
• Användare som är aktiva samtidigt: personer som navigerar, läser eller fyller i ett formulär. Var och en skickar en förfrågan då och då, typiskt var 10:e till 30:e sekund, plus några API-anrop per vy i en modern applikation.
• Förfrågningar under behandling: de som servern beräknar i ett givet ögonblick. Det är den enda storheten som förbrukar processor och minne.

Man går från den ena till den andra med Littles lag: antalet pågående förfrågningar är lika med genomströmningen, i förfrågningar per sekund, multiplicerad med en förfrågans genomsnittliga längd.

Exempel. 600 användare som är aktiva samtidigt, och som var och en utlöser en förfrågan var 20:e sekund, ger 30 förfrågningar per sekund. Om varje förfrågan tar 100 ms har servern i genomsnitt bara 3 pågående förfrågningar. Utmaningen ligger någon annanstans: i topparna och i de långsamma förfrågningarna.

Vad en vCPU klarar

En förfrågan upptar processorn under sin beräkning: köra koden, fråga databasen, bygga svaret. En vCPU hanterar därför högst 1 000 ÷ t förfrågningar per sekund, där t är en förfrågans beräkningstid i millisekunder. Tid som går åt till att vänta (på ett externt API, på en disk) upptar inte processorn, men den upptar en worker.

Med de här storleksordningarna upptar 30 API-förfrågningar per sekund med 10 ms beräkning 30 % av en enda vCPU. Samma 30 förfrågningar per sekund mot WordPress-sidor utan cache kräver 3 till 9 vCPU. Sidcachen finns just för att flytta en sida från tabellens fjärde rad till den andra.

Vad minnet klarar

Varje pågående förfrågan hanteras av en worker, och workers tar minne, oavsett om de arbetar eller inte. Det är ofta minnet, mer än processorn, som bestämmer hur många förfrågningar som hanteras parallellt:

• PHP-FPM: en process per pågående förfrågan, 40 till 80 MB var. pm.max_children sätter taket: 20 processer blir 800 MB till 1,6 GB.
• Python (Gunicorn, Uvicorn): Gunicorns dokumentation föreslår att utgå från (2 × antal kärnor) + 1 workers, med 80 till 200 MB var. En asynkron worker håller många förfrågningar väntande till priset av en enda process.
• Node.js: en enda process håller tusentals anslutningar väntande, men den använder bara en kärna; klusterläget, eller PM2, startar en process per vCPU.
• Databasen: PostgreSQL öppnar en process per anslutning och accepterar 100 som standard. Bortom några tiotal aktiva anslutningar är en anslutningspoolare som PgBouncer bättre än att höja max_connections.

Beständiga anslutningar (websockets, aviseringar i realtid) räknas för sig: de är öppna hela tiden, tar lite processor och några tiotals kilobyte minne var. En Node.js-server håller tusentals av dem inom några hundra MB.

De verkliga flaskhalsarna

I en verklig applikation blir servern sällan överbelastad där man väntar sig. De vanligaste orsakerna, i den ordning du bör leta efter dem:

1. En långsam SQL-fråga: ett saknat index gör en fråga på 2 ms till en fråga på 2 sekunder, som håller kvar en worker och en anslutning. pg_stat_statements i PostgreSQL, eller MySQL:s logg över långsamma frågor, pekar ut den.
2. Frågor i kaskad (N+1-problemet): en sida som kör en fråga per visad rad kör hundratals.
3. Ett synkront externt anrop: ett betalnings- eller AI-API som svarar på 3 sekunder blockerar en synkron worker i 3 sekunder.
4. Tunga bearbetningar i förfrågan: e-postutskick, skalning av bilder, generering av PDF, som bör flyttas till en jobbkö.
5. Avsaknad av cache: sidor som är likadana för alla besökare levereras från en cache, statiska filer från webbservern.

Kontrollera det: belastningstestet

Storleksordningarna ger en första storlek; ett belastningstest ger den verkliga. Principen: simulera allt fler användare mot en kopia av applikationen och notera när svarstiden rusar iväg.

wrk -t2 -c50 -d30s --latency https://test.din-webbplats.com/

För ett helt flöde (inloggning, navigering, sökning) beskriver k6 ett scenario i JavaScript och ökar belastningen i steg:

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

• Testa en kopia, inte produktionen, och meddela din leverantör om testet riktas mot en server som leverantören driver.
• Kör testet från en annan maskin än den server som testas, annars tar verktyget serverns egna resurser.
• Titta på den 95:e percentilen för svarstiden, inte på genomsnittet: det är vad dina sämst betjänade användare upplever.
• Följ servern under testet: htop för processorn, free -h för minnet, loggarna för felen.

När belastningen växer

Den ordning som kostar minst och ger mest:

1. Cacha det som går att cacha (sidor, fragment, frågeresultat) och rätta de långsamma frågorna.
2. Anpassa antalet workers efter tillgängligt minne och tillgänglig processorkraft.
3. Gå upp till en större storlek: fler vCPU och mer minne, utan att ändra något i applikationen.
4. Flytta databasen till en egen server.
5. Fördela applikationen på flera servrar bakom en lastbalanserare.

De tre första stegen räcker för det stora flertalet affärsapplikationer, webbplatser och API:er: flera hundra användare som är aktiva samtidigt ryms på en enda välinställd server.