Tous les articles

Le dimensionnement d'un serveur échoue le plus souvent de deux façons : payer des cœurs qui tournent au ralenti à 3% pendant un an, ou découvrir au lancement que l'ensemble de données actif de la base ne tient pas en RAM. Les deux erreurs viennent du fait de sauter la même étape : dimensionner à partir de la charge de travail plutôt qu'à partir d'une liste de prix. Ce guide vous donne la méthode (référence, marge, croissance), les règles empiriques par charge de travail pour le CPU, la RAM, le stockage et la bande passante, et une réponse honnête sur quand privilégier le scale up ou le scale out.

Un serveur de jeu est une boucle de simulation monothread cadencée sur une horloge fixe : tout se joue sur la vitesse par cœur et la régularité du timing, pas sur le nombre de cœurs. Un VPS mutualisé intercale l'ordonnanceur d'un hyperviseur entre cette boucle et le CPU, et la gigue se traduit par des ticks manqués. Le bare metal supprime cette couche. Ce guide de référence compare le bare metal au VPS et aux panels de jeu managés, explique pourquoi la fréquence compte plus que les cœurs, donne des chiffres de RAM réels pour Minecraft, Rust, ARK, Palworld, Valheim et CS2, fait le point sur le stockage et le DDoS, sur l'auto-hébergement de Pterodactyl ou de son fork Pelican, et liste honnêtement les cas où un VPS reste le bon choix.

Le ping n'est qu'une partie de ce que ressent un joueur. Un aller-retour complet traverse l'échantillonnage de l'entrée, le dernier kilomètre, le transit et le peering, une file d'attente sur le serveur, puis l'attente du prochain tick de simulation avant que le monde ne réagisse. Ce guide détaille d'où vient réellement le délai ressenti, comment le tick rate et le netcode changent la donne, pourquoi le jitter et le packet loss nuisent plus qu'un ping élevé mais stable, et le levier que l'hébergeur maîtrise le plus : placer le serveur près des joueurs, sur du matériel qui tient son tick rate.

Le bare metal l'emporte sur les deux chiffres qui décident si un serveur de jeu est agréable : le temps de tick dans le pire cas et la latence dans le pire cas. Une VM mono-locataire sur du matériel que vous contrôlez s'en approche. C'est sur un VPS multi-locataire survendu que la simulation à tick fixe s'effondre, parce qu'un vCPU ordonnancé avec quelques millisecondes de retard donne un tick manqué que chaque joueur voit sous forme de rubber-banding. Ce guide explique ce qu'un hyperviseur ajoute à une boucle de tick, pourquoi le temps de tick au 95e percentile compte plus que le débit moyen, comment mesurer le steal time et le MSPT sur votre propre serveur, et quand une VM reste le bon choix.

Trois latences distinctes séparent une plateforme de futures d'un moteur d'appariement, et une seule relève du choix d'hébergement. Ce guide les distingue, puis donne les chiffres que nous avons mesurés depuis notre propre site de Chicago vers les passerelles de courtiers auxquelles se connecte réellement une installation NinjaTrader ou Tradovate : 0.2 ms vers la passerelle de données de marché de Rithmic, moins de 1 ms vers sa passerelle d'ordres, environ 3 ms vers celle de CQG. La question qui suit n'est pas tant « VPS ou dédié ». Les deux se trouvent dans la même ville et couvrent la même distance, donc aucun n'est plus proche de quoi que ce soit. Ce qui change, c'est qui d'autre ordonnance le CPU pendant que votre stratégie essaie de terminer un calcul : une question de charge, pas de millisecondes sur une carte.