Discussion :

[Mitolius]

Bonjour/Bonsoir à tous,

je suis en train de développer un jeu en JavaFX qui utilisera le réseau pour stocker/vérifier etc... certaine actions des joueurs. j'utilise pour cela une architecture classique client/serveur avec Socket TCP. Disposant d'un petit VPS chez OVH et voulant rester dans le low cost, j'essaie au maximum d"épargner le serveur ce qui signifie que la partie serveur est en Pool de Thread (je lis une requête, la traite, répond, ferme la Socket). D'un point de vue performance, est-ce mieux d'avoir un serveur (processus) qui traite TOUTE les requête avec un pool de 45 thread ou de split le travail entre 3 serveurs (processus) qui s'occuperai par exemple: 1-Login, 2-Game, 3-Persistance ayant chacun un pool de 15 thread ?

merci d'avance

Mitolius

[adiGuba]

Salut,


Si tes trois applications serveurs vont tourner sur la même machine, je ne vois pas trop l'intérêt qu'il y aurait à découper cela.

De toute manière ils se partageraient les mêmes ressources (CPU, RAM).
La seule différence c'est que tu aurais une limite pour chaque "action" (15 "login", 15 "game" et 15 "persistance") au lieu d'avoir un limite globale (45 "login", "game" ou "persistance").
Mais chaque application serveur aura également son propre espace mémoire (donc + gourmand en RAM, et sûrement une nécessité de partager des infos entre les serveurs).

Maintenant si tu comptes dispatcher cela sur 3 serveurs physiques différents je comprendrais. Mais sur le même serveur j'émets des doutes.

Tu fais quoi comme traitements ? C'est si lourd que cela ?


a++

[OButterlin]

Maintenant si tu comptes dispatcher cela sur 3 serveurs physiques différents je comprendrais. Mais sur le même serveur j'émets des doutes.

D'un point de vue "physique" oui, mais ne penses-tu pas que pour les échanges entre les serveurs, le coût (en temps, cpu, mémoire) via RMI (ou autre) ralentira l'application ?

[adiGuba]

D'un point de vue "physique" oui, mais ne penses-tu pas que pour les échanges entre les serveurs, le coût (en temps, cpu, mémoire) via RMI (ou autre) ralentira l'application ?

Oui bien sûr si tu dispatches les serveurs il y a un coût supplémentaire à prendre en compte, que ce soit en temps, CPU, mémoire...

Il est alors préférable d'avoir un protocole "stateless" (sans session), ce qui impliquera plus de traitement à chaque fois.
Ou alors de mettre en place un mécanisme de partage des sessions et des données...


Bref c'est pas forcément le genre de truc adapté pour le "low cost".


a++

[Mitolius]

Merci de vos réponse, ce serai un fonctionnement stateless en effet et les joueur ne serai pas connecté tout le temps, juste le temps du login, ensuite il envoie une requête pour persister l’état du jeu par exemple. et le serveur n'aurai aucun besoin de parler a un client sans avoir reçu une requête ! Donc je vois a part mettre une limite par "type" (login, persistance, etc...) cela n'apporte aucun up de performance sur la JVM. Merci de vos réponse