Calculateur de Ressources VPS

D'abord la nature de la charge, pas le nom du paquet

Lors du choix d'un VPS, le nom du paquet trompe facilement. « Basic », « standard », « premium », « usage général »… Ils ont fière allure. Mais aucun de ces noms ne dit à lui seul combien de RAM le site va consommer, quand il saturera le CPU, ni quel jour le disque sera plein.

Un site statique et une boutique WooCommerce n'ont pas besoin du même serveur, même s'ils reçoivent le même nombre de visiteurs. Dans l'un, on sert des fichiers prêts à l'emploi ; dans l'autre, il y a le panier, le paiement, le stock, la session utilisateur, les requêtes de base de données, le panneau d'administration, et parfois des tâches en file d'attente en arrière-plan. C'est exactement là que se situe la différence.

Ce modèle de calcul lit le VPS à travers quatre ressources principales : vCPU, RAM, disque et trafic mensuel. Mais il ne les prend pas comme de simples chiffres ; il les évalue en tenant compte du type d'application, du niveau de l'environnement, de l'utilisation du cache/CDN, des services fonctionnant sur le même VPS, des journaux, des sauvegardes locales et de la marge de croissance.

Il n'existe pas de « formule VPS officielle ». D'ailleurs, dans la documentation des grands fournisseurs de cloud, le problème est abordé de cette façon : le CPU, la mémoire, le réseau et le stockage sont considérés ensemble ; les familles de machines sont également réparties en fonction de la charge de travail. Les machines polyvalentes se comportent différemment des machines orientées calcul, et les machines orientées mémoire encore différemment. Sur le plan des VPS, la même logique s'applique, mais à plus petite échelle.

flowchart LR
  A["Type d’application"] --> E["Estimation des ressources"]
  B["Trafic et cache"] --> E
  C["Base de données, worker, panneau d’administration, Docker"] --> E
  D["Disque, logs, sauvegardes, marge de croissance"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disque"]
  E --> I["Trafic mensuel"]

La phrase que je déteste le plus dans ce genre de calculs est : « 2 vCPU suffisent. » Pour quoi ? Pour un site statique, pour WooCommerce, pour Odoo, pour une API Node, ou pour une installation mixte avec MySQL, Redis, la messagerie et Docker sur la même machine ?

La différence entre le CPU partagé et le CPU dédié est aussi négligée. Dans les petits plans VPS, le CPU est souvent partagé. Cela peut ne pas être un problème pour les sites web légers. Mais sur les systèmes qui exécutent des workers réguliers, qui reçoivent des pics de trafic, qui génèrent des rapports ou qui sollicitent fréquemment la base de données, le même nombre de vCPU peut sembler plus faible que prévu.

C'est pourquoi le résultat fourni ici ne doit pas être lu comme un « plan précis », mais comme une estimation de départ sûre. Il donne une bonne première image pour le choix des ressources. En production, ce sont les métriques qui ont le dernier mot : l'utilisation du CPU, la consommation de RAM, le remplissage du disque, le trafic réseau, les requêtes lentes, les journaux d'erreurs, la file de workers.

Le papier est une chose, le serveur en est une autre.

Par où commencer ?

La première distinction du calcul vient du type d'application, car la charge de base n'est pas la même pour chaque classe d'application.

Le site statique se situe du côté le plus léger. On part de 1 vCPU et 1 Go de RAM ; le facteur CPU est également maintenu bas, à 0,2. C'est logique. Sur un site statique bien mis en cache, le serveur sert la plupart du temps des fichiers prêts à l'emploi, la couche applicative travaille très peu.

Pour WordPress / blog, le point de départ est plus élevé : 1,5 vCPU, 2 Go de RAM, facteur CPU de 1. WordPress a une base PHP et base de données. Thème, extensions, traitement des images, opérations d'administration, recherche, commentaires : il ne se comporte pas comme un site statique. Il peut néanmoins être considérablement soulagé avec un cache correct.

WooCommerce / e-commerce est une autre classe. Dans ce modèle, on prend 2,5 vCPU, 4 Go de RAM, et un facteur CPU de 2. Si vous me demandez, cette distinction est indispensable pour l'e-commerce. Car WooCommerce ajoute une couche panier, paiement, commande, stock et adhésion par-dessus WordPress standard. De plus, certaines pages ne se prêtent pas à une mise en cache complète. La page produit peut provenir du cache, mais c'est différent pour le panier et le paiement.

Pour les applications Laravel / PHP et Node.js / API, on part de 2 vCPU, 3 Go de RAM, facteur CPU de 1,2. Ici, le besoin réel dépend beaucoup du code. Une API simple peut fonctionner très légèrement ; une application qui parle à des services externes, traite des données en continu, utilise des files d'attente, peut être beaucoup plus lourde dans la même classe.

Pour un petit SaaS, on part de 3 vCPU, 4 Go de RAM, facteur CPU de 1,8. Session utilisateur, tâches d'arrière-plan, notifications, rapports et trafic de base de données vont généralement ensemble. Le nombre de visiteurs peut sembler faible, mais le nombre d'opérations internes est élevé. En y regardant comme pour un site web, on choisit le mauvais forfait.

Les systèmes de type Odoo / ERP sont du côté lourd : 4 vCPU, 8 Go de RAM, facteur CPU de 3. Dans les installations Odoo, la planification des workers et de la mémoire est d'ailleurs réfléchie séparément. Rapports, session utilisateur, modules, opérations de base de données et tâches de longue durée distinguent cette classe d'un site de blog normal.

Pour un serveur de jeu, on part de 3 vCPU, 4 Go de RAM, facteur CPU de 2,5 ; côté bot / worker, on part de 2 vCPU, 2 Go de RAM, facteur CPU de 1,5. En particulier pour les tâches de type worker, le nombre de visiteurs peut être trompeur. Même si personne ne visite le site, des données sont traitées en arrière-plan.

Le choix de l'environnement s'ajoute comme un coefficient sur la valeur de base. On considère 0,75 pour un environnement de test / loisir, 1 pour une petite production, 1,25 pour la production, 1,6 pour une préparation à la haute disponibilité. « Préparation à la haute disponibilité » ne signifie pas qu'un VPS unique est désormais HA ; cela signifie simplement réserver une part de ressources plus large. La vraie HA exige une architecture distincte.

La marge de croissance entre également en jeu à la toute fin. Par défaut, 30 %. Je trouve cela raisonnable. C'est une bonne fourchette pour couvrir une attente de croissance sur 3 à 6 mois. On peut écrire 300 %, mais si cette croissance n'est pas réellement attendue, le calcul devient un calcul de peur.

Calcul du trafic : la moyenne mensuelle est un peu trompeuse

Le nombre de visiteurs mensuels est la première donnée à regarder, mais elle reste insuffisante pour une décision finale. Deux sites recevant 100 000 visiteurs ne produisent pas forcément la même charge. L'un affiche 1,5 page par visiteur, une taille de page de 1 Mo, et le CDN fonctionne bien. L'autre affiche 4 pages par visiteur, une taille de page de 3 Mo, et davantage de zones dynamiques. Même visiteur, charge serveur radicalement différente.

Le calcul du trafic prend en compte le nombre de visiteurs, la valeur pages / session et la taille moyenne des pages. On y soustrait l'effet du cache, on ajoute la marge de croissance, et le résultat est converti en Go. La valeur finale est arrondie par paliers de 50 Go ; même dans les scénarios très petits, un trafic minimum de 50 Go est affiché.

Côté cache, les hypothèses utilisées sont les suivantes : pas de cache = économie de 0 %, cache de base = 35 %, cache de page + object cache = 60 %, CDN + cache puissant = 75 %. Ce ne sont pas des valeurs de garantie officielles. Avec un cache NGINX ou un CDN, on s'attend à une réduction de la charge sur le serveur d'origine ; mais l'économie réelle dépend du taux de succès du cache, de la structure des pages et des zones dynamiques.

Soyez particulièrement attentif à cela avec WooCommerce. Le fait d'avoir un CDN ne rend pas soudainement gratuites les pages panier et paiement. Le cache est plus limité pour le contenu personnalisé, les sessions, les opérations d'administration, le flux de paiement, le contrôle des stocks. Le cache est un bon frein, mais il ne remplace pas le moteur.

Il y a aussi le facteur de pointe horaire. Le trafic mensuel n'est pas uniformément réparti. Jour de campagne, envoi de newsletter, partage sur les réseaux sociaux, pics soudains sur les sites d'actualité… Pendant que la valeur moyenne semble calme, le serveur peut transpirer pendant une heure. Dans ce calcul, le pic de RPS est approximativement obtenu en divisant le produit (visiteurs mensuels × pages / session × facteur de pointe horaire) par le nombre de secondes sur 30 jours. 30 jours = 2 592 000 secondes.

L'effet du trafic sur le CPU est encore plus intéressant. Le nombre de visiteurs est rapporté à 50 000, multiplié par le facteur CPU, on ajoute le facteur de pointe horaire, et on soustrait la moitié de l'effet du cache côté CPU. Autrement dit, le cache réduit sérieusement le trafic, mais l'effet sur le CPU est réduit avec plus de prudence. Je pense que c'est la bonne approche, car toutes les requêtes ne proviennent pas du cache.

Dans le test d'un site statique mis en cache, avec 100 000 visiteurs mensuels, 1,5 page / session, une taille de page de 1 Mo, un facteur de pointe horaire de 2, CDN + cache puissant et une marge de croissance de 20 %, le résultat reste à 1 vCPU, 2 Go de RAM, 40 Go de disque et 50 Go de trafic mensuel. Il y a du trafic, mais la charge est légère.

Dans l'exemple de l'e-commerce, le confort n'est pas le même. Avec 200 000 visiteurs mensuels, 4 pages / session, une taille moyenne de page de 3 Mo, un facteur de pointe horaire de 5, cache de page + object cache et une marge de croissance de 50 %, le trafic mensuel atteint 1 450 Go. La recommandation CPU est de 32 vCPU. Cela peut sembler élevé à première vue, mais en additionnant les chiffres, le tableau se durcit : plus de visiteurs, plus de pages, des pages plus lourdes, une charge de travail plus importante, un pic plus élevé.

La taille des pages est un autre fléau. Dire « le site est léger » ne suffit pas, il faut mesurer. Les grandes images, les polices, les scripts tiers, les codes publicitaires, les étiquettes d'analyse, les fichiers JS inutiles gonflent le trafic. Le fait qu'il se charge rapidement dans le navigateur ne signifie pas que le transfert de données est faible.

Qui travaille dans la même boîte ?

C'est souvent là que se joue la vraie bagarre sur les petits VPS. Le serveur web ne fonctionne pas tout seul. MySQL est au même endroit, Redis aussi, le panneau aussi, peut-être même le service de messagerie. Ajoutez des conteneurs Docker et des processus worker, et les 2 Go de RAM suffoquent.

Si la base de données se trouve sur le même VPS, le modèle ajoute une surcharge de RAM. La taille de la base est divisée par 20 ; le résultat est plafonné entre 1 Go et 8 Go. Par exemple, pour une base de 5 Go, on réserve déjà 1 Go de RAM. Pour une base de 30 Go, la surcharge est d'environ 1,5 Go. Côté CPU, on ajoute 0,5 vCPU pour la base de données.

Ces valeurs ne constituent pas un calcul de réglage de base de données. Si les index sont mauvais, les requêtes trop longues, ou s'il y a des verrous de table, 0,5 vCPU ne suffira pas. Mais pour une première planification, c'est mieux que de considérer la base de données comme sans coût.

Si Redis / object cache est sur le même VPS, on ajoute 0,5 Go de RAM. Redis fonctionne en mémoire ; oublier cela provoque d'étranges ralentissements sur un petit serveur. Il a été installé pour améliorer les performances du cache, oui, mais il a aussi besoin de RAM.

Pour le panneau d'administration, il y a trois niveaux : aucun, panneau léger, panneau complet type cPanel / Plesk. Le panneau léger ajoute 0,3 Go de RAM et 0,15 vCPU au CPU. Le panneau complet ajoute 1 Go de RAM et 0,3 vCPU. Installer cPanel ou des systèmes similaires sur un VPS de 1 Go de RAM puis attendre des performances de la part de l'application n'est pas une très bonne idée. Le panneau apporte du confort ; vous le payez en ressources.

Le nombre de workers / files d'attente a un impact direct. Pour chaque worker, on ajoute 0,5 Go de RAM et 0,5 vCPU. Cela peut sembler un peu élevé, mais c'est logique si les tâches d'arrière-plan sont consistantes. Traitement d'images, génération de rapports, récupération de données depuis une API externe, vidage de la file d'emails, tâches post-paiement… Si le worker n'est pas inactif, il consomme des ressources.

Si le service de messagerie fonctionne sur le même VPS, on ajoute 0,5 Go de RAM et 0,3 vCPU. Outre la partie ressources, un service de messagerie est aussi exigeant sur le plan opérationnel. DNS, SPF, DKIM, DMARC, spam, file d'attente, délivrabilité. Ce calcul ne voit que la part de ressources ; il ne calcule pas les maux de tête.

Pour l'utilisation de Docker / conteneurs, on ajoute 0,5 Go de RAM et 0,2 vCPU. Docker apporte de l'ordre, mais il n'est pas gratuit. Si la limite de mémoire de Docker, le comportement du swap et la part de CPU ne sont pas correctement réglés, un conteneur peut étouffer toute la machine. « On a fait des conteneurs, on est tranquilles » n'est pas toujours la bonne phrase.

L'essentiel du calcul CPU est le suivant : on prend le plus grand entre le CPU de base et le besoin CPU lié au trafic, on ajoute les charges CPU des services, on applique le coefficient d'environnement et la marge de croissance. Pour la RAM, on additionne la RAM de base et la RAM des services, puis on applique de nouveau l'environnement et la marge de croissance. Ensuite, le résultat est arrondi aux paliers pratiques de forfaits : 1, 2, 4, 6, 8, 12, 16, 24, 32, 64 pour le CPU ; 1, 2, 4, 8, 16, 32, 64, 128 Go pour la RAM.

Pas de monde fractionnaire. Si le besoin est de 5,3 Go de RAM, on regarde vers 8 Go. Si le besoin est de 3,1 vCPU, 4 vCPU sont raisonnables. Faire un calcul au millimètre en environnement de production rapproche du mur à la moindre fluctuation.

Sur le disque, la vraie charge est parfois ce que l'on ne voit pas

On pense que le besoin en disque est faible parce que le dossier du code est petit. C'est une erreur de calcul que nous voyons souvent. L'application fait 3 Go, les médias 10 Go ; on dit « 20 Go de disque suffisent ». Puis arrivent les journaux, la base de données, la sauvegarde locale, les fichiers système, les images de conteneurs, les fichiers temporaires.

Le calcul du disque se fait avec les fichiers de l'application, les médias / uploads, la taille de la base de données, le journal quotidien, la durée de conservation des journaux et la copie de sauvegarde locale. Si la base de données n'est pas sur le même VPS, elle n'entre pas dans le calcul du disque. Si elle y est, elle y entre.

D'abord, on crée le sous-total du disque : fichiers de l'application + fichiers médias + base de données (si elle est sur le même VPS) + journal quotidien × jours de conservation. Ensuite, on compte le nombre de copies de sauvegarde locales. Une sauvegarde locale fait grossir l'ensemble de données d'environ une fois de plus. On ajoute 15 Go de part système, on applique une marge de sécurité de 20 %, puis on ajoute la marge de croissance. Le résultat est arrondi par paliers de 10 Go, avec un minimum recommandé de 20 Go.

Ne sous-estimez pas la part système de 15 Go. Le système d'exploitation, les paquets, les résidus de mise à jour, les fichiers temporaires, les journaux de services, les images Docker, les fichiers temporaires de la base de données en consomment. En production, le disque n'est pas seulement votre dossier d'upload.

Les journaux sont sournois. 0,5 Go de journaux par jour et 14 jours de conservation font 7 Go. 2 Go de journaux par jour et 30 jours de conservation font 60 Go. Ils grossissent silencieusement. Le disque dépasse 80 %, puis 90 %, puis pendant un déploiement, cette fameuse erreur : no space left on device.

La sauvegarde locale demande aussi de l'attention. Garder une sauvegarde sur le même disque n'est pas une garantie totale en cas de catastrophe ; si le disque disparaît, la sauvegarde disparaît aussi. Mais une copie locale peut servir pour un retour rapide. Le modèle l'inclut dans le calcul des ressources. Des décisions comme la sauvegarde distante, le stockage d'objets ou un serveur de sauvegarde séparé doivent être planifiées séparément.

Dans le test de production WordPress, avec 5 Go de fichiers d'application, 10 Go de médias, 5 Go de base de données, 0,5 Go de journaux par jour, 14 jours de conservation, 1 sauvegarde locale et une marge de croissance de 30 %, le disque recommandé est de 90 Go. À première vue, c'est beaucoup. Mais quand on ajoute les journaux, la sauvegarde, la part système et la marge de sécurité, ce n'est pas excessif, c'est plutôt prudent.

Côté e-commerce, l'affaire grossit : 10 Go de fichiers d'application, 80 Go de médias, 30 Go de base de données, 2 Go de journaux par jour, 30 jours de conservation, 1 sauvegarde locale et une marge de croissance de 50 %. Le disque résultant est de 480 Go. Si les images produits, les données de commandes, les journaux et la sauvegarde sont dans la même boîte, ce résultat n'est pas surprenant.

Économiser excessivement sur le disque est une mauvaise habitude. Si le CPU manque, vous voyez des ralentissements. Si la RAM manque, le swap se met en route. Si le disque est plein, les services peuvent se dégrader bien plus durement : la base de données ne peut plus écrire, les journaux ne se créent pas, le fichier de session ne peut pas s'ouvrir, le déploiement reste incomplet. Pire encore, l'erreur ne s'explique pas toujours clairement.

Quand on convertit le résultat en forfait

La sortie comporte quatre valeurs principales : CPU, RAM, disque et trafic mensuel. Ne les mettez pas toutes dans le même sac. Chacune indique une limite différente.

Le CPU, c'est la puissance de traitement instantanée. Requête PHP, réponse d'API Node.js, requête de base de données, tâche worker, opération post-paiement… Tout cela touche le CPU. Quand le trafic augmente, le CPU peut augmenter ; le cache peut le réduire, mais pas l'effacer complètement.

La RAM, c'est l'espace des services en cours d'exécution. MySQL, Redis, PHP-FPM, processus Node.js, panneau, conteneurs Docker, service de messagerie, workers. Quand la RAM diminue, le système peut basculer sur le swap. Il a l'air de fonctionner, mais il ralentit. Cette différence se ressent vite, surtout dans les applications dynamiques.

Le disque, c'est le stockage persistant. Fichiers d'application, médias, base de données, journaux, sauvegardes et fichiers système y regardent. Dans le calcul du disque, il faut penser non pas à la taille actuelle, mais à l'accumulation dans quelques mois.

Le trafic mensuel, c'est le transfert de données. Le CDN, le cache et l'optimisation des pages le réduisent. Il faut aussi vérifier la politique de trafic du fournisseur : y a-t-il un quota, des frais de dépassement, une réduction de débit ? Le calcul donne le besoin en Go ; il ne donne pas la condition commerciale du fournisseur.

Dans ce modèle, les valeurs brutes sont arrondies aux paliers pratiques de forfaits. Si le besoin brut est de 3,4 vCPU, on recommande 4 vCPU. Si le besoin est de 9 Go de RAM, on peut passer à 16 Go. Le disque est aussi complété par paliers de 10 Go. Cet arrondi montre parfois un résultat plus grand qu'il n'est, mais les forfaits VPS ne se vendent de toute façon pas en valeurs fractionnaires.

Il y a aussi ceci : 4 vCPU ne se comportent pas forcément comme 4 vCPU chez tous les fournisseurs. La génération du CPU, la structure partagée / dédiée, la couche de virtualisation, le type de disque, la qualité du réseau, les machines voisines, tout cela fait une différence. La distinction entre CPU partagé et CPU dédié n'est pas mise en avant pour rien dans les documents de choix de plans de fournisseurs comme DigitalOcean.

C'est pourquoi ce calcul doit être considéré comme un contrôle technique avant d'appuyer sur le bouton d'achat. Si vous avez un système existant, mettez-le en regard des métriques réelles : graphique CPU, utilisation RAM, remplissage disque, trafic sortant, requêtes lentes, erreurs 5xx, temps d'attente en file. Si vous montez un nouveau système, testez plusieurs scénarios.

Que se passe-t-il sans cache ? De combien le trafic baisse-t-il si on choisit un CDN ? La RAM est-elle soulagée si on sépare la base de données du VPS ? Où va le CPU quand le nombre de workers passe de 0 à 4 ? De combien la copie de sauvegarde locale augmente-t-elle le disque ?

Le choix du forfait vient parfois des réponses à ces questions, pas d'une seule ligne de résultat.

Si c'était moi, je revérifierais surtout trois valeurs : le facteur de pointe horaire, le fait que la base de données soit ou non sur le même VPS, et la copie de sauvegarde locale. Car dans la vraie vie, ce sont celles qui perturbent le plus le calcul. Le trafic se concentre sur une heure, MySQL consomme plus de RAM que prévu sur la même machine, les sauvegardes remplissent le disque. Ensuite, tout le monde s'en prend au forfait CPU.

Parfois, la faute n'est pas au CPU.