Combien d'utilisateurs simultanés tient un VPS : faire le calcul

Des utilisateurs aux requêtes

« Utilisateurs simultanés » désigne trois grandeurs différentes selon qui parle :

• Les comptes inscrits : ils ne coûtent rien au serveur tant qu’ils ne se connectent pas.
• Les utilisateurs actifs en même temps : des personnes qui naviguent, lisent, remplissent un formulaire. Chacune envoie une requête de temps en temps, typiquement toutes les 10 à 30 secondes, plus quelques appels d'API par écran dans une application moderne.
• Les requêtes en cours de traitement : celles que le serveur calcule à un instant donné. C'est la seule grandeur qui consomme du processeur et de la mémoire.

On passe de l'une à l'autre par la loi de Little : le nombre de requêtes en cours est égal au débit, en requêtes par seconde, multiplié par la durée moyenne d'une requête.

Exemple. 600 utilisateurs actifs en même temps, qui déclenchent chacun une requête toutes les 20 secondes, font 30 requêtes par seconde. Si chaque requête dure 100 ms, le serveur n'a que 3 requêtes en cours en moyenne. L'enjeu est ailleurs : dans les pics et dans les requêtes lentes.

Ce que tient un vCPU

Une requête occupe le processeur le temps de son calcul : exécuter le code, interroger la base, construire la réponse. Un vCPU traite donc au plus 1 000 ÷ t requêtes par seconde, où t est le temps de calcul d'une requête en millisecondes. Le temps passé à attendre (une API externe, un disque) n'occupe pas le processeur, mais il occupe un worker.

Avec ces ordres de grandeur, 30 requêtes d'API par seconde à 10 ms de calcul occupent 30 % d'un seul vCPU. Les mêmes 30 requêtes par seconde sur des pages WordPress sans cache demandent 3 à 9 vCPU. Le cache de pages sert précisément à faire passer une page de la quatrième ligne du tableau à la deuxième.

Ce que tient la mémoire

Chaque requête en cours est prise en charge par un worker, et les workers occupent de la mémoire, qu'ils travaillent ou non. C'est souvent la mémoire, plus que le processeur, qui fixe le nombre de requêtes traitées en parallèle :

• PHP-FPM : un processus par requête en cours, 40 à 80 Mo chacun. pm.max_children fixe le plafond : 20 processus, c’est 800 Mo à 1,6 Go.
• Python (Gunicorn, Uvicorn) : la documentation de Gunicorn propose de partir de (2 × nombre de cœurs) + 1 workers, de 80 à 200 Mo chacun. Un worker asynchrone garde de nombreuses requêtes en attente pour le prix d'un seul processus.
• Node.js : un seul processus garde des milliers de connexions en attente, mais il n'utilise qu'un cœur ; le mode cluster, ou PM2, lance un processus par vCPU.
• La base de données : PostgreSQL ouvre un processus par connexion et en accepte 100 par défaut. Au-delà de quelques dizaines de connexions actives, un regroupeur comme PgBouncer vaut mieux qu'une hausse de max_connections.

Les connexions persistantes (websockets, notifications en temps réel) se comptent à part : ouvertes en permanence, elles occupent peu de processeur et quelques dizaines de kilo-octets de mémoire chacune. Un serveur Node.js en tient des milliers dans quelques centaines de Mo.

Les vrais goulots d’étranglement

Sur une application réelle, le serveur sature rarement là où on l'attend. Les causes les plus fréquentes, dans l'ordre où les chercher :

1. Une requête SQL lente : un index manquant transforme une requête de 2 ms en une requête de 2 secondes, qui retient un worker et une connexion. pg_stat_statements sur PostgreSQL, ou le journal des requêtes lentes de MySQL, la désigne.
2. Les requêtes en cascade (le problème N+1) : une page qui lance une requête par ligne affichée en lance des centaines.
3. Un appel externe synchrone : une API de paiement ou d'IA qui répond en 3 secondes bloque un worker synchrone pendant 3 secondes.
4. Des traitements lourds dans la requête : envoi d'e-mails, redimensionnement d'images, génération de PDF, à déplacer dans une file de tâches.
5. L'absence de cache : les pages identiques pour tous les visiteurs se servent depuis un cache, les fichiers statiques depuis le serveur web.

Le vérifier : le test de charge

Les ordres de grandeur donnent une première taille ; un test de charge donne la vraie. Le principe : simuler des utilisateurs de plus en plus nombreux sur une copie de l'application, et relever le moment où le temps de réponse décroche.

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

Pour un parcours complet (connexion, navigation, recherche), k6 décrit un scénario en JavaScript et fait monter la charge par paliers :

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

• Testez une copie, pas la production, et prévenez votre hébergeur si le test vise un serveur qu'il exploite.
• Lancez le test depuis une autre machine que le serveur testé, sinon l'outil lui prend ses propres ressources.
• Regardez le 95^e centile du temps de réponse, pas la moyenne : c’est ce que vivent vos utilisateurs les moins bien servis.
• Observez le serveur pendant le test : htop pour le processeur, free -h pour la mémoire, les journaux pour les erreurs.

Quand la charge grandit

L'ordre qui coûte le moins et rapporte le plus :

1. Mettre en cache ce qui peut l’être (pages, fragments, résultats de requêtes) et corriger les requêtes lentes.
2. Régler le nombre de workers sur la mémoire et le processeur disponibles.
3. Passer à une taille supérieure : plus de vCPU et de mémoire, sans rien changer à l'application.
4. Placer la base de données sur son propre serveur.
5. Répartir l'application sur plusieurs serveurs derrière un répartiteur de charge.

Les trois premières étapes couvrent la grande majorité des applications de gestion, des sites et des API : plusieurs centaines d'utilisateurs actifs en même temps tiennent sur un seul serveur bien réglé.