Quanti utenti simultanei regge un VPS: fare il calcolo

Dagli utenti alle richieste

«Utenti simultanei» indica tre grandezze diverse a seconda di chi parla:

• Gli account registrati: non costano nulla al server finché non si collegano.
• Gli utenti attivi nello stesso momento: persone che navigano, leggono, compilano un modulo. Ognuna invia una richiesta di tanto in tanto, tipicamente a intervalli compresi tra 10 e 30 secondi, più qualche chiamata API per schermata in un'applicazione moderna.
• Le richieste in corso di elaborazione: quelle che il server calcola in un dato istante. È l'unica grandezza che consuma processore e memoria.

Si passa dall'una all'altra con la legge di Little: il numero di richieste in corso è uguale al numero di richieste al secondo moltiplicato per la durata media di una richiesta.

Esempio. 600 utenti attivi nello stesso momento, che attivano ciascuno una richiesta ogni 20 secondi, fanno 30 richieste al secondo. Se ogni richiesta dura 100 ms, il server ha in media solo 3 richieste in corso. La vera sfida è altrove: nei picchi e nelle richieste lente.

Quanto regge un vCPU

Una richiesta occupa il processore per il tempo del suo calcolo: eseguire il codice, interrogare il database, costruire la risposta. Un vCPU elabora quindi al massimo 1.000 ÷ t richieste al secondo, dove t è il tempo di calcolo di una richiesta in millisecondi. Il tempo passato ad attendere (un'API esterna, un disco) non occupa il processore, ma occupa un worker.

Con questi ordini di grandezza, 30 richieste API al secondo a 10 ms di calcolo occupano il 30% di un solo vCPU. Le stesse 30 richieste al secondo su pagine WordPress senza cache richiedono da 3 a 9 vCPU. La cache delle pagine serve proprio a far passare una pagina dalla quarta riga della tabella alla seconda.

Quanto regge la memoria

Ogni richiesta in corso è presa in carico da un worker, e i worker occupano memoria, che lavorino o no. Spesso è la memoria, più del processore, a decidere il numero di richieste elaborate in parallelo:

• PHP-FPM: un processo per richiesta in corso, da 40 a 80 MB ciascuno. pm.max_children fissa il tetto: 20 processi significano da 800 MB a 1,6 GB.
• Python (Gunicorn, Uvicorn): la documentazione di Gunicorn suggerisce di partire da (2 × numero di core) + 1 worker, da 80 a 200 MB ciascuno. Un worker asincrono tiene molte richieste in attesa con l'ingombro di un solo processo.
• Node.js: un solo processo tiene migliaia di connessioni in attesa, ma usa un solo core; la modalità cluster, o PM2, avvia un processo per vCPU.
• Il database: PostgreSQL apre un processo per connessione e ne accetta 100 per impostazione predefinita. Oltre qualche decina di connessioni attive, un pooler come PgBouncer è preferibile a un aumento di max_connections.

Le connessioni persistenti (websocket, notifiche in tempo reale) si contano a parte: aperte in permanenza, occupano poco processore e qualche decina di kilobyte di memoria ciascuna. Un server Node.js ne regge migliaia in qualche centinaio di MB.

I veri colli di bottiglia

Su un'applicazione reale, il server raramente si satura dove ce lo si aspetta. Le cause più frequenti, nell'ordine in cui cercarle:

1. Una query SQL lenta: un indice mancante trasforma una query da 2 ms in una da 2 secondi, che trattiene un worker e una connessione. pg_stat_statements su PostgreSQL, o lo slow query log di MySQL, la individua.
2. Le query a cascata (il problema N+1): una pagina che lancia una query per ogni riga visualizzata ne lancia centinaia.
3. Una chiamata esterna sincrona: un'API di pagamento o di IA che risponde in 3 secondi blocca un worker sincrono per 3 secondi.
4. Elaborazioni pesanti dentro la richiesta: invio di email, ridimensionamento di immagini, generazione di PDF, da spostare in una coda di job.
5. L'assenza di cache: le pagine identiche per tutti i visitatori si servono da una cache, i file statici dal server web.

Verificarlo: il test di carico

Gli ordini di grandezza danno una prima taglia; un test di carico dà quella vera. Il principio: simulare utenti sempre più numerosi su una copia dell'applicazione, e rilevare il momento in cui il tempo di risposta peggiora di colpo.

wrk -t2 -c50 -d30s --latency https://preprod.vostro-sito.com/

Per un percorso completo (accesso, navigazione, ricerca), k6 descrive uno scenario in JavaScript e fa salire il carico per gradi:

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

• Testate una copia, non la produzione, e avvisate il vostro provider di hosting se il test punta a un server che gestisce lui.
• Lanciate il test da un'altra macchina rispetto al server testato, altrimenti lo strumento gli sottrae le sue stesse risorse.
• Guardate il 95º percentile del tempo di risposta, non la media: è ciò che vivono gli utenti serviti peggio.
• Osservate il server durante il test: htop per il processore, free -h per la memoria, i log per gli errori.

Quando il carico cresce

L'ordine che costa meno e rende di più:

1. Mettere in cache ciò che si può (pagine, frammenti, risultati di query) e correggere le query lente.
2. Regolare il numero di worker sulla memoria e sul processore disponibili.
3. Passare a una taglia superiore: più vCPU e memoria, senza cambiare nulla nell'applicazione.
4. Spostare il database su un server tutto suo.
5. Distribuire l'applicazione su più server dietro un bilanciatore di carico.

Le prime tre fasi coprono la grande maggioranza delle applicazioni gestionali, dei siti e delle API: diverse centinaia di utenti attivi nello stesso momento stanno su un solo server ben regolato.