Tester un serveur cloud pendant l'essai : checklist pratique
Un serveur cloud se commande vite et se juge mal sur une grille tarifaire. Un essai court montre si le CPU, le disque, le réseau et le support conviennent à votre charge, mais seulement si vous arrivez avec un plan. DCXV ne propose pas d'essai gratuit en libre-service. Un essai court, d'environ 3 jours, peut être demandé en écrivant à sales@dcxv.com. L'accorder relève de DCXV, donc rien ici ne promet une acceptation ; confirmez par écrit la durée, la taille, l'emplacement et les frais éventuels avant de commencer. Une image d'évaluation de Windows Server est un média Microsoft, pas un essai DCXV, et elle n'inclut pas de licences RDS utilisateur.
Trois jours donnent un premier verdict, pas une évaluation complète. Imprimez cette page, cochez les cases et notez le chiffre à côté de chaque résultat.
Avant de commencer : définissez ce qui est bon
- Décrivez la charge en une phrase.
- Choisissez deux ou trois chiffres pour accepter ou refuser : temps de réponse, temps de requête, temps de restauration.
- Choisissez l'emplacement le plus proche de vos utilisateurs, Prague ou Covilhã ; le guide des emplacements explique le compromis.
- Demandez une taille proche de celle que vous achèteriez. Le guide de dimensionnement aide ; les presets de la page serveurs cloud démarrent à EUR 15.00/mois pour 2 vCPU, 4 Go de RAM, 40 Go NVMe (vérifié 2026-10).
- Lisez la politique d'utilisation acceptable sur /policy.
Jour 1 : déployer et vérifier l'accès
- Notez le délai entre la commande et une connexion fonctionnelle ; le site indique généralement moins de 10 minutes.
- Connectez-vous en root par SSH (Linux) ou RDP (Windows) : se connecter en SSH.
- Ouvrez une fois la console de récupération KVM, avant d'en avoir besoin.
- Lancez
lscpu,free -h,df -het comparez avec votre commande. - Mettez à jour le système et vérifiez que l'IPv4 publique répond depuis l'extérieur.
Jour 2 : références CPU, mémoire, disque et réseau
Réglez les threads sur votre nombre de vCPU et gardez chaque exécution courte.
sysbench cpu --threads=2 --time=30 run
sysbench memory --threads=2 --time=30 run
fio --name=rand4k --filename=/root/fio.tmp --size=1G --rw=randrw --bs=4k --iodepth=16 --ioengine=libaio --direct=1 --runtime=30 --time_based
mtr -rwc 100 YOUR_SERVER_IP
- Lancez le test CPU deux fois à des heures différentes et notez les deux résultats.
- Notez les IOPS et la latence du disque, puis supprimez /root/fio.tmp.
- Lancez mtr depuis votre bureau vers le serveur ; lire la sortie de mtr explique les colonnes.
- Téléchargez un fichier connu et notez la vitesse. Un fichier, pas un test de saturation.
Jour 3 : charge réelle, restauration, verdict
- Déployez l'application réelle et rejouez un trafic normal, pas un déluge.
- Créez un snapshot, modifiez un fichier, cliquez sur Restore et vérifiez que la modification a disparu. Une restauration arrête le serveur et abandonne son état actuel. Les snapshots sont une option payante : demandez au support s'ils sont facturés pendant un essai et supprimez le vôtre ensuite.
- Ouvrez la fenêtre Backups (date et taille par sauvegarde ; guide de restauration). Ne restaurez que des données jetables et demandez si une première sauvegarde existera dans les 3 jours.
- Posez au support une vraie question et chronométrez la première réponse utile.
- Remplissez la grille d'évaluation et décidez.
| Domaine | À noter | Réussi si |
|---|---|---|
| CPU et mémoire | sysbench, deux passes | Stable et suffisant pour votre pic |
| Disque | fio IOPS, latence | Rien n'attend le disque |
| Réseau | mtr perte, moyenne | Propre pour vos utilisateurs |
| Reprise, support | durée, première réponse | Vous pouvez récupérer et être aidé |
Si vous obtenez une évaluation plus longue
- Semaine 1 : répétez les tests du jour 2 le matin, le soir et la nuit.
- Semaine 2 : faites passer du trafic réel, surveillez mémoire et swap, redémarrez une fois volontairement.
- Semaine 2 : essayez un changement d'offre ; un disque ne peut pas être réduit sans formatage.
- Semaine 3 : répétez la migration, une restauration complète et la facture selon le guide des coûts.
Pratiques de benchmark sans danger
- Testez court et petit : 30 à 60 secondes, un fichier de 1 Go, puis nettoyez.
- L'AUP interdit le flooding, le déni de service, les scanners de ports et d'IP, la force brute et les attaques. Ne les lancez jamais, pas même contre votre propre serveur.
- Demandez au support avant tout test lourd : des heures de CPU au maximum, de gros transferts, beaucoup de connexions. Pas de vraies données clients sur un serveur d'essai.
- Un test court est un échantillon, pas une garantie ; les voisins, l'heure et la charge changent les résultats.
Demandez votre essai
Écrivez à sales@dcxv.com avec la charge, la taille, l'emplacement et la durée, et demandez si vous êtes éligible. Pour démarrer tout de suite, choisissez une taille sur la page serveurs cloud.
