Configuration matérielle et réseau requise pour les serveurs Source Engine

Le Source engine est un moteur de jeu 3D développé par Valve. Le Source engine est reconnu pour ses avancées en matière de physique, d'IA et de graphismes qui rendaient les jeux réalistes pour l'époque, tout en restant scalable sur du matériel plus ancien et moins puissant. Les serveurs Source engine sont des services de jeu hébergés qui permettent aux joueurs de se connecter et de jouer ensemble dans le monde du serveur. Les serveurs sous Source engine peuvent être personnalisés avec des mods, ce qui donne une expérience de jeu unique et souvent amusante pour tous les joueurs connectés au serveur.

Parmi les jeux tournant sous le Source engine, on trouve Team Fortress 2, Counter-Strike: Source, Garry's Mod, et bien d'autres !

Une question fréquemment posée est de savoir quels sont les besoins matériels et réseau pour héberger un serveur Source engine, ainsi que comment cela se compare aux serveurs d'autres jeux comme Minecraft et Rust. La réponse à cette question est : ça dépend vraiment.

Bien que les serveurs Source engine soient beaucoup plus légers en utilisation de RAM comparé à d'autres jeux comme Minecraft et Rust, ils sont majoritairement monothread. Cela signifie qu'un processeur avec peu de cœurs mais de hautes performances monothread sera plus performant qu'un processeur avec de nombreux cœurs mais de faibles performances monothread pour les serveurs Source engine. C'est particulièrement vrai si vous prévoyez d'héberger un mode de jeu intensif ou de faire connecter beaucoup de joueurs en même temps sur le serveur.

Cela dit, voici une liste de facteurs supplémentaires à prendre en compte lorsque vous décidez de vos besoins matériels et réseau.

• Le nombre maximal de joueurs que le serveur aura connectés et jouant simultanément.
• Le mode de jeu, la quantité de mods, et le type de maps que fait tourner le serveur.
• Le tickrate du serveur.
• Les valeurs des ConVar liées à la performance du serveur.

Si vous voulez les meilleures performances possibles et que vous en avez les moyens, je vous suggère personnellement de chercher un serveur équipé d'un CPU issu d'une liste telle que les benchmarks CPU les mieux notés pour les performances monothread de Passmark.

Joueurs simultanés

Plus il y a de joueurs connectés au serveur en même temps, plus il y a de données réseau échangées entre chaque client, et généralement plus il se passe de choses dans le jeu et sur le serveur lui-même, ce qui entraîne une utilisation CPU plus élevée.

Bien qu'il n'existe pas de règle générale sur les vitesses monothread et le nombre de joueurs, car il y a énormément d'autres variables, si vous prévoyez d'avoir beaucoup de joueurs connectés simultanément au serveur, vous devriez essayer d'acquérir un CPU plus moderne avec de meilleures performances monothread.

Mode de jeu, quantité de mods et types de maps

Ce sont des facteurs très importants à prendre en compte lorsque vous décidez des besoins de votre serveur. Par exemple, un serveur faisant tourner un mode de jeu comme le Deathmatch dans Counter-Strike: Source, où les joueurs tirent constamment les uns sur les autres, réapparaissent et courent partout, va très probablement consommer plus de ressources qu'un serveur faisant tourner un mode de jeu où, lorsque les joueurs meurent, ils ne réapparaissent qu'au round suivant.

Cela dit, les maps en espaces confinés ou celles utilisant beaucoup de props physiques vont très probablement consommer plus de puissance CPU qu'une map plus grande et plus ouverte.

Le tickrate du serveur

Le tickrate correspond à la fréquence à laquelle le serveur simule le jeu. Par défaut, le tickrate d'un serveur est réglé sur 66.66... (toutes les 15ms). Cette valeur peut être modifiée à l'aide de l'argument de ligne de commande -tickrate dans la commande de démarrage du serveur, si le jeu ou un mod permet aux administrateurs du serveur de le changer.

Plus le tickrate du serveur est élevé, plus il nécessite de puissance CPU et de bande passante. Cela entraîne également l'envoi et la réception d'un plus grand nombre de mises à jour vers et depuis les clients, ce qui améliore la latence côté client, la détection des impacts (hit registration), et plus encore !

Il existe de nombreux serveurs sur Garry's Mod qui hébergent jusqu'à 128 joueurs connectés simultanément. Ils y parviennent en faisant tourner une valeur de tickrate basse, comme 33 ou 22, ce qui est suffisamment bas pour que le CPU puisse gérer la charge générale du serveur dans la plupart des cas (selon le serveur, bien sûr).

Les valeurs des ConVar liées à la performance du serveur

Il existe quelques ConVars liées à la performance du serveur que vous pouvez modifier sur le serveur, et qui influencent la quantité de CPU et de bande passante consommée par votre serveur. Cela dit, ces paramètres peuvent avoir un impact sur la latence du client, le nombre de paquets perdus, le choke, et plus encore.

Voici une liste de quelques ConVars liées à la performance que j'ai trouvées les plus bénéfiques.

• sv_maxrate - Le débit de bande passante maximum autorisé pour le client (à la fois entrant et sortant) par seconde sur le serveur, en "bytes". Mettre cette valeur à 0 indique illimité et est recommandé si vous avez la capacité réseau et matérielle nécessaire.
• sv_minrate - Le débit de bande passante minimum autorisé pour le client (à la fois entrant et sortant) par seconde sur le serveur, en "bytes".
• sv_maxupdaterate - Le nombre maximum de paquets update par seconde que le serveur peut envoyer à un client. Cette valeur est généralement égale au tickrate de votre serveur. Cependant, dans certains cas, elle peut être abaissée pour réduire la charge sur le CPU ou l'utilisation de la bande passante.
• sv_minupdaterate - Le nombre minimum de paquets update par seconde que le serveur peut envoyer au client. Cette valeur se situe généralement entre 0 et la moitié du tickrate de votre serveur (par exemple, 33).
• sv_maxcmdrate - Le nombre maximum de paquets command par seconde que le serveur peut envoyer au client. Cette valeur est généralement égale au tickrate de votre serveur. Cependant, dans certains cas, elle peut être abaissée pour réduire la charge sur le CPU ou l'utilisation de la bande passante.
• sv_mincmdrate - Le nombre minimum de paquets command par seconde que le serveur peut envoyer au client. Cette valeur se situe généralement entre 0 et la moitié du tickrate de votre serveur (par exemple, 33).
• net_splitpacket_maxrate - Le nombre maximum de bytes par seconde que le serveur peut envoyer sous forme de paquets fragmentés (split packets) au client. Mettre cette valeur plus haute, comme 128000, peut aider dans les situations où du choke se produit avec beaucoup de données réseau transmises en même temps.
• net_maxcleartime - Le temps maximum en secondes que le serveur passera à traiter et envoyer des données réseau en un seul tick. Mettre cette valeur basse, comme 0.001, peut réduire le choke dans certaines situations, mais nécessitera plus de puissance CPU.
• sv_parallel_sendsnapshot - Quand elle est à 1, cette valeur permet au serveur d'utiliser un thread séparé pour préparer les snapshots de l'état du jeu pour chaque client. Cela peut grandement améliorer les performances du serveur dans les environnements avec beaucoup de joueurs.

Je recommande de lire à propos du Source Multiplayer Networking pour mieux comprendre à quelles valeurs ces paramètres devraient être définis. J'ai trouvé ce sujet de NFOservers.com extrêmement instructif et utile également !

Si vous utilisez un fournisseur d'hébergement dédié, vous aurez très probablement la capacité réseau nécessaire pour régler ces valeurs de ConVar à des valeurs élevées/illimitées. Dans ce cas, les valeurs suivantes devraient fonctionner dans la plupart des cas.

sv_maxrate 0
sv_minrate 75000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_maxcmdrate 66
sv_mincmdrate 20
net_splitpacket_maxrate 128000
net_maxcleartime 0.001
sv_parallel_sendsnapshot 1

Si vous n'êtes toujours pas sûr des valeurs à définir pour ces ConVars liées à la performance, je recommande d'utiliser un outil comme celui-ci pour calculer les valeurs. Cela dit, il est recommandé d'effectuer un test de vitesse réseau à l'aide d'outils comme SpeedTest.net ou CloudFlare pour obtenir les vitesses réseau de téléversement et de téléchargement de votre serveur. Ces vitesses réseau jouent un rôle important dans le nombre de joueurs que vous pouvez avoir connectés simultanément au serveur avant de rencontrer des problèmes liés au réseau tels que la perte de paquets, etc. (en particulier votre vitesse de téléversement, car elle indique la quantité de bande passante que vous pouvez envoyer à tous les joueurs en même temps sur Internet).

Surveillance des performances du serveur

Le meilleur outil intégré au jeu pour surveiller les performances du serveur dans les jeux sous Source engine est le Net Graph. Vous pouvez afficher le net graph en ajustant votre valeur net_graph dans la console développeur, de 0 à 4.

Cet outil affiche la quantité de bande passante que vous envoyez et recevez du serveur auquel vous êtes connecté, les FPS du serveur, le nombre de mises à jour que vous et le serveur envoyez/recevez, et plus encore !

Une explication plus détaillée du Net Graph peut être trouvée ici.

Voici quelques informations tirées de la page Wiki liée précédemment :

Area 1

Cette zone est la légende des couleurs utilisées dans la section payload du graphique. Si une partie du payload arrive mais ne correspond à aucune des catégories prédéterminées, elle est représentée dans la zone claire entre la dernière couleur et le petit point blanc qui représente la taille totale du paquet (voir l'indicateur a sur l'image)

Area 2

Pour les paquets supérieurs à 300 bytes qui se trouvent dans le 95e percentile, la taille du paquet est affichée en texte en haut de la zone payload (voir le marqueur 2). Notez que la technologie Orange Box utilise la compression sur les paquets, mais les tailles indiquées dans le payload du net_graph sont basées sur la taille du payload décompressé.

Area 3

Les images par seconde de la connexion locale ainsi que le ping aller-retour vers le serveur sont affichés dans la zone 3.

Area 4

Cette zone affiche l'utilisation actuelle de la bande passante. Les valeurs in/out montrent la taille en bytes du dernier paquet entrant et sortant. Le k/s affiche les kilobytes par seconde (moyenne mobile) observés récemment dans chaque direction.

Area 5

Cette zone affiche les performances du serveur auquel le client est connecté. L'indicateur sv montre les FPS du serveur au moment de la dernière mise à jour réseau reçue par le client. Le var montre l'écart type du frametime du serveur (où server fps = 1.0 / frametime) sur les 50 dernières frames enregistrées par le serveur. Si le framerate du serveur est inférieur à 20 fps, cette ligne s'affichera en jaune. Si le framerate du serveur est inférieur à 10 fps, cette ligne s'affichera en rouge.

Area 6

L'indicateur lerp montre le nombre de msecs d'interpolation utilisé par le client. Quelques notes sur la valeur de lerp suivent ci-dessous.

Area 7

Cette zone affiche le paramètre cl_updaterate actuel de l'utilisateur, le nombre réel de mises à jour par seconde effectivement reçues du serveur, le nombre réel de paquets par seconde envoyés au serveur, ainsi que le paramètre cl_cmdrate de l'utilisateur (qui représente le nombre de paquets par seconde que l'utilisateur souhaite envoyer au serveur).

Area 8

Lorsque net_graphshowlatency est à 1, cette zone affiche un historique de la latence de la connexion. La hauteur (indiquée par le repère d) correspond à la valeur de net_graphmsecs (il y a en réalité un peu de marge après net_graphmsecs en haut pour que les champs de texte puissent s'y insérer). Les lignes verticales rouges indiquent des paquets perdus entre le serveur et le client. Si le graphique affiche un repère jaune (comme au repère c), cela indique que le serveur a dû retenir un ou plusieurs paquets avant d'envoyer une mise à jour au client.

Area 9

Lorsque net_graphshowinterp est à 1, cette zone affiche pour chaque frame du client la quantité d'interpolation nécessaire. S'il y a un grand écart entre les paquets (perte de paquets, framerate du serveur trop faible, etc.), le client n'aura pas suffisamment de données pour interpoler et commencera à extrapoler. L'extrapolation est représentée par des barres orange s'élevant au-dessus de la ligne blanche (une séquence d'extrapolation est visible juste à gauche du repère 9). De plus, le tout dernier pixel en bas indique si un paquet CUserCmd (usercmd) a été envoyé sur cette frame de rendu, ou retenu par le client et agrégé en raison du paramètre cl_cmdrate de l'utilisateur.

Dedicated Hosting VS LAN Server

Bien qu'il soit possible d'héberger un serveur public sur votre réseau domestique (LAN), cela n'est pas recommandé. À la place, vous devriez acheter un serveur auprès d'un fournisseur d'hébergement dédié.

Bien que les frais d'abonnement qui accompagnent souvent l'hébergement dédié soient généralement considérés comme un gros inconvénient, voici quelques raisons d'utiliser l'hébergement dédié :

• Meilleure protection contre les attaques (D)DoS grâce à une capacité réseau plus élevée et à des systèmes de mitigation spécifiquement conçus pour gérer les attaques.
• Meilleur routage client et meilleure latence.
• Plus stable (par exemple, si une coupure de courant survient chez vous, le serveur ne sera pas mis hors ligne).

De plus, voici quelques raisons de ne pas héberger votre serveur chez vous.

• Certains FAI sont contre l'hébergement d'un serveur de jeu public sur votre réseau domestique.
• Des coûts d'électricité et de bande passante réseau domestique plus élevés, selon le nombre de serveurs hébergés, la charge du serveur, le processeur du serveur, etc.

See Also

• NFOservers - Guide de résolution du lag pour les jeux Valve
• Valve - Source Multiplayer Networking
• Source Dedicated Server Rate Calculator 2015
• Valve - TF2 Net Graph

https://moddingcommunity.com/blog/how-to-download-run-steamcmd/

Conclusion

Cela conclut ce guide/article de la base de connaissances. Vous devriez maintenant mieux comprendre quel matériel et quel réseau vous nécessitez pour héberger un serveur sur le moteur Source.

Si vous avez des questions ou des retours concernant ce guide, veuillez répondre à son sujet de forum ici ! Ce guide continuera d'être travaillé et amélioré au fil du temps.

Rejoignez notre serveur Discord !