Performances et fiabilité

Le temps de vol est le pourcentage de temps où votre CPU virtuel était prêt à s'exécuter mais où l'hyperviseur a donné le cœur physique à quelqu'un d'autre. Il apparaît comme la colonne "st" dans top. Tout ce qui est constamment au-dessus de 2–3 % signifie que vous êtes en concurrence pour le cœur, et c'est la cause habituelle des pics de latence inexpliqués sur une instance à vCPU partagé.

Par ordre de probabilité : épuisement de la mémoire provoquant des échanges (swap) excessifs, saturation des E/S disque, temps de vol du CPU sur les cœurs partagés, base de données non optimisée, ou latence réseau vers vos utilisateurs. Vérifiez d'abord free -h et la colonne st dans top — entre eux, ils identifient la cause environ quatre-vingts pour cent du temps.

Au sein d'une métropole, moins de 5 ms. Au sein d'un continent, 10–40 ms. Transatlantique, 70–90 ms. Europe vers Asie, 150–200 ms. Routes antipodales, 250–320 ms. La lumière dans la fibre se déplace à environ deux tiers de c et les chemins réels sont environ 1,35 fois la distance orthodromique, donc environ 1 ms pour 100 km par trajet est le minimum.

Une instance bien configurée de 2 vCPU / 4 Go sert un site statique à des millions de visites mensuelles, un site WordPress en cache à environ 300 000, et une application dynamique non mise en cache à peut-être 30 000. La variable qui domine est la mise en cache, pas le matériel — la même instance diffère de deux ordres de grandeur selon elle.

Mesurez les trois choses qui varient réellement : le CPU mono-thread avec sysbench, le disque avec fio en lecture/écriture aléatoire 4K, et le réseau avec iperf3 vers un point de terminaison connu. Exécutez chaque test plusieurs fois à différentes heures — un benchmark unique mesure cette minute, pas le serveur.

Environ cinq fois les IOPS aléatoires — environ 500 000 contre 90 000 — et environ cinq fois la latence en moins, sous 0,1 ms contre environ 0,5 ms. Le débit séquentiel est six à dix fois plus élevé. Pour les applications basées sur des bases de données, l'écart d'IOPS aléatoires est celui que vous ressentez réellement.

Notre SLA est de 99,99 % par instance, ce qui permet environ 4,4 minutes d'indisponibilité par mois, et la disponibilité observée sur l'ensemble du parc au cours des douze derniers mois était de 99,993 %. Au-delà, cela nécessite une redondance que vous construisez vous-même — une machine unique, aussi bonne soit-elle, est un point de défaillance unique.

Indirectement et de manière mesurable. Les moteurs de recherche ne classent pas en fonction du pays du serveur, mais ils mesurent la vitesse de la page, et la distance est la latence. Un serveur à 200 ms de vos utilisateurs coûte de vrais points Core Web Vitals. Utilisez un CDN si votre public est mondial ; placez l'origine près de votre public s'il est régional.

La protection DDoS filtre le trafic d'attaque en amont de votre serveur afin que les requêtes légitimes arrivent toujours. Elle doit être permanente pour être utile : une atténuation qui s'active après le début d'une attaque vous a déjà fait tomber. OnionVPS inclut jusqu'à 12 Tbit/s de filtrage L3/L4 à chaque niveau, y compris le forfait à 4 $.

L'isolation est solide : KVM impose la séparation au niveau matériel, et s'en échapper est une faille de niveau recherche. Le risque réaliste n'est pas l'hyperviseur, c'est votre configuration. Le SSH par mot de passe, les logiciels non corrigés et un service ouvert oublié représentent l'essentiel des compromissions réelles.

Un vCPU partagé est planifié avec d'autres clients, donc en cas de contention, votre processus attend, ce qui se voit comme du temps volé. Un vCPU dédié est un thread physique réservé pour vous, rien d'autre n'y est planifié. Le partagé convient pour un travail inactif la plupart du temps ; le dédié est nécessaire pour tout ce qui a une exigence de latence.