Câți utilizatori simultani suportă un VPS: cum faceți calculul

De la utilizatori la cereri

„Utilizatori simultani” desemnează trei mărimi diferite, după cine vorbește:

• Conturile înregistrate: nu îl costă nimic pe server cât timp nu se conectează.
• Utilizatorii activi în același timp: persoane care navighează, citesc, completează un formular. Fiecare trimite o cerere din când în când, de obicei la fiecare 10 până la 30 de secunde, plus câteva apeluri API pe ecran într-o aplicație modernă.
• Cererile în curs de procesare: cele pe care serverul le calculează la un moment dat. Este singura mărime care consumă procesor și memorie.

Se trece de la una la alta prin legea lui Little: numărul de cereri în curs este egal cu debitul, în cereri pe secundă, înmulțit cu durata medie a unei cereri.

Exemplu. 600 de utilizatori activi în același timp, care declanșează fiecare câte o cerere la fiecare 20 de secunde, produc 30 de cereri pe secundă. Dacă fiecare cerere durează 100 ms, serverul are în medie doar 3 cereri în curs. Miza este în altă parte: în vârfuri și în cererile lente.

Cât susține un vCPU

O cerere ocupă procesorul pe durata calculului său: executarea codului, interogarea bazei de date, construirea răspunsului. Un vCPU procesează deci cel mult 1.000 ÷ t cereri pe secundă, unde t este timpul de calcul al unei cereri, în milisecunde. Timpul petrecut în așteptare (un API extern, un disc) nu ocupă procesorul, dar ocupă un worker.

Cu aceste ordine de mărime, 30 de cereri API pe secundă la 10 ms de calcul ocupă 30% dintr-un singur vCPU. Aceleași 30 de cereri pe secundă pe pagini WordPress fără cache cer între 3 și 9 vCPU. Cache-ul de pagini servește tocmai la mutarea unei pagini de pe al patrulea rând al tabelului pe al doilea.

Cât susține memoria

Fiecare cerere în curs este preluată de un worker, iar workerii ocupă memorie, fie că lucrează, fie că nu. Adesea memoria, mai mult decât procesorul, stabilește numărul de cereri procesate în paralel:

• PHP-FPM: un proces pentru fiecare cerere în curs, între 40 și 80 MB fiecare. pm.max_children stabilește plafonul: 20 de procese înseamnă între 800 MB și 1,6 GB.
• Python (Gunicorn, Uvicorn): documentația Gunicorn propune să porniți de la (2 × numărul de nuclee) + 1 workeri, între 80 și 200 MB fiecare. Un worker asincron ține numeroase cereri în așteptare folosind un singur proces.
• Node.js: un singur proces ține mii de conexiuni în așteptare, dar folosește un singur nucleu; modul cluster sau PM2 lansează câte un proces pe vCPU.
• Baza de date: PostgreSQL deschide un proces pentru fiecare conexiune și acceptă implicit 100. Peste câteva zeci de conexiuni active, un pooler de conexiuni precum PgBouncer este mai potrivit decât o creștere a max_connections.

Conexiunile persistente (websocketuri, notificări în timp real) se socotesc separat: deschise permanent, ele ocupă puțin procesor și câteva zeci de kiloocteți de memorie fiecare. Un server Node.js ține mii de astfel de conexiuni în câteva sute de MB.

Adevăratele blocaje

Într-o aplicație reală, serverul se saturează rareori acolo unde vă așteptați. Cauzele cele mai frecvente, în ordinea în care merită căutate:

1. O interogare SQL lentă: un index lipsă transformă o interogare de 2 ms într-una de 2 secunde, care reține un worker și o conexiune. pg_stat_statements pe PostgreSQL sau jurnalul interogărilor lente din MySQL o identifică.
2. Interogările în cascadă (problema N+1): o pagină care lansează o interogare pentru fiecare rând afișat lansează sute.
3. Un apel extern sincron: un API de plăți sau de AI care răspunde în 3 secunde blochează un worker sincron timp de 3 secunde.
4. Procesări grele în interiorul cererii: trimiterea de e-mailuri, redimensionarea imaginilor, generarea de PDF-uri, care se mută într-o coadă de sarcini.
5. Lipsa cache-ului: paginile identice pentru toți vizitatorii se servesc dintr-un cache, fișierele statice direct de serverul web.

Verificarea: testul de încărcare

Ordinele de mărime dau o primă dimensiune; un test de încărcare o dă pe cea reală. Principiul: simulați tot mai mulți utilizatori pe o copie a aplicației și notați momentul în care timpul de răspuns se degradează brusc.

wrk -t2 -c50 -d30s --latency https://preprod.site-ul-dumneavoastra.com/

Pentru un parcurs complet (autentificare, navigare, căutare), k6 descrie un scenariu în JavaScript și crește încărcarea pe trepte:

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://preprod.site-ul-dumneavoastra.com/');
  sleep(15);
}

• Testați o copie, nu producția, și anunțați furnizorul de găzduire dacă testul vizează un server pe care îl exploatează el.
• Lansați testul de pe altă mașină decât serverul testat, altfel instrumentul îi consumă propriile resurse.
• Urmăriți percentila a 95-a a timpului de răspuns, nu media: ea arată ce trăiesc utilizatorii dumneavoastră cel mai slab serviți.
• Observați serverul în timpul testului: htop pentru procesor, free -h pentru memorie, jurnalele pentru erori.

Când încărcarea crește

Ordinea care costă cel mai puțin și aduce cel mai mult:

1. Puneți în cache tot ce se poate (pagini, fragmente, rezultate de interogări) și corectați interogările lente.
2. Reglați numărul de workeri după memoria și procesorul disponibile.
3. Treceți la o dimensiune superioară: mai multe vCPU și mai multă memorie, fără nicio schimbare în aplicație.
4. Mutați baza de date pe propriul ei server.
5. Distribuiți aplicația pe mai multe servere, în spatele unui echilibrator de încărcare (load balancer).

Primele trei etape acoperă marea majoritate a aplicațiilor de gestiune, a site-urilor și a API-urilor: câteva sute de utilizatori activi în același timp încap pe un singur server bine reglat.