VPS Ubuntu

Comparer la même facture mensuelle

Les montants ci-dessous sont inventés pour expliquer le calcul. Ils supposent une VM, une IPv4 requise, le même besoin de sauvegarde et le même trafic. Taxes et administration sont exclues des deux colonnes.

Faites défiler le tableau pour voir toutes les colonnes →

Le tarif affiché à 6 devient 11 dans cet exemple. Calculez votre total avec les vraies unités, devises, taxes, quotas et dépassements. Vérifiez le prix au renouvellement et les ressources facturées après arrêt.

Confirmez aussi les restrictions réseau, notamment SMTP sortant si vous envoyez des e-mails. Pour une offre infogérée, détaillez les tâches incluses : correctifs, incidents applicatifs, sauvegardes et assistance à la restauration. L’adresse de contact de ce site ne détermine pas la région du serveur.

Un quota gratuit et un crédit temporaire ont des conditions différentes. Le comparatif gratuit les distingue ; la configuration du premier site s’adresse à un serveur déjà disponible.

Décrivez les composants et une opération représentative. Exemple hypothétique : catalogue dynamique, Nginx, un service applicatif, PostgreSQL et un import planifié. Une VM de 2 vCPU et 4 Go est un premier essai, pas une capacité prouvée. Utilisez les mêmes données de test, version, cache et nombre de processus pour chaque candidat.

Relever l’état pendant le scénario

Sur Ubuntu, sysstat fournit iostat. Installez-le si nécessaire, puis lancez les échantillonnages dans des terminaux séparés pendant votre charge de test. Un relevé au repos ne décrit que l’état initial.

free -h
df -h /
sudo apt update
sudo apt install sysstat
vmstat 1 11
iostat -xz -y 1 10

Dans free, regardez available : une partie du cache est récupérable. La première ligne d’activité vmstat résume la période depuis le démarrage ; utilisez les suivantes pour l’échantillon. L’option -y d’iostat saute son premier rapport cumulé. Contrôlez aussi les autres volumes si la base n’est pas sur /.

Observation du serveur d’origine de ce site le 24 septembre 2026 : un CPU logique visible et 957 Mio de mémoire, avec 59 Mio libres mais 358 Mio disponibles. Le panneau et d’autres services étaient inclus. Ce relevé illustre la différence entre free et available ; ce n’était pas un test de charge.

Vérifier les parcours utiles

Dans un environnement que vous contrôlez, testez recherche, connexion, écriture et tâches de fond, avec et sans cache. Fixez les délais et taux d’erreur acceptables avant de comparer. Depuis un client proche des utilisateurs, adaptez ce point de test ; les durées sont en secondes.

curl -sS -o /dev/null --max-time 30 -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.com/catalogue

Une requête curl ne mesure pas la concurrence. Pour un test de charge, utilisez un client séparé, le même scénario, un débit, une concurrence, une durée et un jeu de données notés. Comparez erreurs et 95e percentile, seuil sous lequel se situent 95 % des requêtes mesurées.

Faites défiler le tableau pour voir toutes les colonnes →

Ce sont des indices. Du swap alloué peut contenir d’anciennes pages ; await inclut attente et traitement. Un verrou SQL peut ralentir sans saturer CPU ou RAM. Reliez mesures et journaux, puis changez une variable majeure à la fois. Choisissez la configuration qui satisfait charge, croissance et récupération au coût acceptable.