Bien que tu ais faux, je penses que certains hébergeurs souhaites faire croire cela. Je penses que c'est surtout affaire de business ce qui est logique. Donner plus de RAM et un processeur moins puissant est plus intéressant qu'une offre avec le meilleur processeur ma fois aujourd'hui la qualité de beaucoup d'hébergeur sont remonté après l'arrivé de nouveaux concurrents et nouveaux processeurs.
L'un des plus beau hébergeur niveau arnaque (et c'est bien mon avis personnel) c'est Myriapulse et j'ai été client... Quand avec ram "illimité" les TPS de ton serveur parte en cacahuète sans avoir changé les réglages de bases, c'est qu'il y à un soucis.
Apres un serveur Mc fonctionne sur un seul cœur, soit, mais la RAM elle n'est jamais consommé au maximum par l'utilisateur. C'est très simple d'ajouter une petite barrette dans un serveur plutôt que de changer le processeur à cause de pleins de petits soucis qui peuvent survenir (OS, réglages, alimentation(la ram elle est bien moins délicate) etc).
En fait c'est surtout que la RAM est bien plus inter-changeable que le CPU dans le sens où changer de CPU veut souvent dire changer de carte mère, parfois d'alimentation pour que ça tienne et même parfois de châssis si la chaleur est trop importante (notamment pour du bi-CPU).
Bref de tels changements coûtent chers et ne sont même tout simplement pas possibles dès que l'hébergeur n'est pas propriétaire de ses propres machines. C'est notre cas à nous aussi, on est plus flexibles de se débarrasser d'une machine au profit d'une autre mais finalement un tel changement de CPU implique de migrer toute la machine avec tout ce qui est logiciellement dessus (sauf si on virtualise mais entre malus de performances, coûts de licence et complications, on évite).
Pour les TPS qui décrochent, c'est juste que la JVM ne suit plus la cadence de 20 TPS, la cause peut être multiple :
- processeur qui ne fournit pas assez de cycles de calcul car trop chargé par des serveurs voisins
- le serveur Minecraft qui demande trop de ressources
Il nous arrive d'avoir des machines chargées à 20% et des serveurs qui bouffent 1 coeur CPU avec des TPS qui partent en vrille, même parfois des TPS qui décrochent juste parce qu'il y a trop d'entités ou un circuit redstone/command block bien pourri.
C'est donc plus compliqué qu'il n'y parait.
Les coeur n'étant du coup pas dédier cela provoque aussi des surcharges à ce niveaux là je pense. Il vaut donc mieux un plus petit processeur avec au moin un coeur dédier à Minecraft plustôt qu'un gros processeur dont le coeur seras offert à je ne sait combien de serveur.
En théorie c'est un peu ça, en pratique c'est beaucoup plus compliqué. En soi plein de serveurs sur une machine n'est pas impactant si la majorité sont inactifs (dans le sens ne consomment pas/peu de cycles CPU, des fois ça bouffe bien niveau CPU avec 0 joueur connecté...), c'est en ça que la mutualisation est un risque et que la quantité de serveurs hébergés sur une machine est une question de probabilité où parfois on joue à la loterie ^^
Par contre la notion de coeur dédié n'a plus beaucoup de sens aujourd'hui, les processeurs modernes gèrent très bien la montée en charge et la parallélisation, le gain à attendre d'un coeur dédié en terme de performances est souvent proche de 0 (en comparaison à une mutualisation raisonnable bien entendu).
Car pour prendre une comparaison simple, je vais comparez MineCraft et Garry's Mod.
Ce sont tous deux des jeux très mal développer dans leurs façons de gérez un équilibre entre RAM et processeur.
Minecraft lui lit tous le code et le stock en RAM pour le sortir vite. Il ne videras que très rarement ce qu'il à stocker. Ce qui fait donc de lui un gros problèmes au niveau de la RAM.
Par contre Garry's Mod lui lit en continue le code qu'on peu lui forunir. Il ne stock quasiment rien en RAM. Je peu en donner un exemple concret que j'ai vécus. Un serveur Garry's Mod avec une panoplie d'addons et 64 personnes connecter ne demanderas qu'a peine 1 à 2Go de RAM par contre le coeur du processeur seras utiliser à presque 100% tous le temps provoquant donc des chutes de TPS.
On héberge beaucoup de Garry's Mod également et pour le coup ce sont 2 environnements techniques très différents, à commencer par Java vs C++. Le premier est très très gourmand en mémoire, c'est un fait commun et même si le GC s'améliore avec le temps, c'est gourmand en RAM qu'importe l'utilisation.
Après les jeux n'ont rien à voir, les maps sur Gmod sont statiques, seuls les props changent donc pas grand chose à stocker en comparaison avec un univers sandbox potentiellement infini avec des chunks devant être préchargés à la volée selon les déplacements de joueurs (alors que sur Gmod les joueurs téléchargent la map en local avant de rejoindre le serveur).
Sinon
@robin4002 a bien résumé les choses, un CPU plus véloce en fréquence va de toute façon tenir bien davantage et si ce n'est pas indispensable comme caractéristique pour un petit serveur, au-delà d'une dizaine de slots c'est très important. Aussi lorsque vous faites du WorldEdit un peu lourd ou autre, il n'y a pas de match entre un CPU récent qui pointe à 2,4Ghz et un autre à 3,5Ghz.
Dans tous les cas les serveurs de jeux sont globalement quasiment pas multi-thread, la fréquence est très importante, au même titre que l'architecture où les améliorations de génération en génération sont relativement constantes, même si sur le papier ce n'est pas flagrant.
Sa ouvre un peu l'esprit au niveaux serveur.
