Salut,
pour ma part, je pense qu'un hébergement mutualisé (performance, par exemple) est suffisant pour pas mal de jeux (en termes de perf', pas de configuration: le mutualisé n'est pas aussi configurable qu'un VPS ou un dédié).
Le nombre de joueurs n'est pas le plus important. Ce qui comptera, ce sera la charge serveur, principalement dictée par le nombre de joueurs jouant en même temps (minimum, maximum, moyenne).
Si le plus gros de la sollicitation se trouve dans le SQL (cela me semble normal d'ailleurs), alors il peut être intéressant d'utiliser un hébergement simple/léger pour l'interface web (type mutualisé) et un serveur plus lourd coté SQL.
Pour mes projets (Eclerd, DevianTools, blog, Mantis bug tracker...), j'ai un mutualisé Performances, capable de se connecter à un SQL privé (128Mo RAM). Ce SQL privé, au besoin, pourra être upgradé (256, 512, 1G de RAM, voire peut-être plus). C'est largement suffisant (les lenteurs d'Eclerd sont causées par un code affreusement mauvais).
Je terminerai en disant tout dépendra de tes moyens financiers et temporels. Si tu as plus de temps que de moyens, sous-dimensionne ton serveur, et upgrade quand la demande se fera sentir. Si tu as plus de moyens que de temps (rare!), sur-dimensionne ton serveur pour ne pas perdre quelques jours (ou quelques joueurs) à upgrader. Mais comme pour l'optimisation, je pense que le dimensionnement du serveur doit se faire en fonction des besoins. Optimiser pour le plaisir d'optimiser n'apporte rien: on optimise uniquement si le besoin s'en fait sentir. De même, avoir un gros serveur pour avoir un gros serveur n'apporte rien: partir de plus petit et le gonfler au besoin me semble plus approprié (mais cela demande du temps pour migrer).
Note qu'upgrader est souvent simple (chez un hébergeur), downgrader est plus complexe.
pour ma part, je pense qu'un hébergement mutualisé (performance, par exemple) est suffisant pour pas mal de jeux (en termes de perf', pas de configuration: le mutualisé n'est pas aussi configurable qu'un VPS ou un dédié).
Le nombre de joueurs n'est pas le plus important. Ce qui comptera, ce sera la charge serveur, principalement dictée par le nombre de joueurs jouant en même temps (minimum, maximum, moyenne).
Si le plus gros de la sollicitation se trouve dans le SQL (cela me semble normal d'ailleurs), alors il peut être intéressant d'utiliser un hébergement simple/léger pour l'interface web (type mutualisé) et un serveur plus lourd coté SQL.
Pour mes projets (Eclerd, DevianTools, blog, Mantis bug tracker...), j'ai un mutualisé Performances, capable de se connecter à un SQL privé (128Mo RAM). Ce SQL privé, au besoin, pourra être upgradé (256, 512, 1G de RAM, voire peut-être plus). C'est largement suffisant (les lenteurs d'Eclerd sont causées par un code affreusement mauvais).
Je terminerai en disant tout dépendra de tes moyens financiers et temporels. Si tu as plus de temps que de moyens, sous-dimensionne ton serveur, et upgrade quand la demande se fera sentir. Si tu as plus de moyens que de temps (rare!), sur-dimensionne ton serveur pour ne pas perdre quelques jours (ou quelques joueurs) à upgrader. Mais comme pour l'optimisation, je pense que le dimensionnement du serveur doit se faire en fonction des besoins. Optimiser pour le plaisir d'optimiser n'apporte rien: on optimise uniquement si le besoin s'en fait sentir. De même, avoir un gros serveur pour avoir un gros serveur n'apporte rien: partir de plus petit et le gonfler au besoin me semble plus approprié (mais cela demande du temps pour migrer).
Note qu'upgrader est souvent simple (chez un hébergeur), downgrader est plus complexe.