Architecture Serveur Multi-thread ou pas

Version imprimable

06/07/2008, 16h25
Richard Cypher

Architecture Serveur Multi-thread ou pas

Bonjour,

Je me renseigne sur la manière concevoir un serveur qui puisse tenir la charge avec énormement de clients connectés en même temps (dans les 3k ou 4k utilisateurs).

Je réfléchis à la manière d'implémenter l'architecture d'un serveur de jeux massivement multi-joueurs. Pour l'instant je me concentre uniquement sur le chat.

J'ai déja réalisé des mini-serveus multi-threads de tchat , je trouve le concept du muti-thread pas mal . Mais habituellement ce qu'on voit sur tous les exemples sur le net ou ce que l'on nous enseigne en cours c'est de créer un thread pour chaque client qui se connecte au serveur, et c'est ce thread qui sera en charge de la communication pour le client.

Le soucis que je vois dans une architecture comme celle-ci , c'est que si on a 4k clients qui se connectent au serveur , il va falloir créer 4k threads , et que le système devra switcher entre tous les threads , dans ces conditions je pense que le serveur sera incapable de tenir la charge ?

Combien de threads un gros serveur( 2*quadri coeurs) peut supporter avant que les performances s'effondrent ?

J'ai entendu parler des "pools de thread" , es que cela pourrait résoudre le problème , comment cela s'utilise t'il ?

Peutêtre que l'utilisation des threads n'est pas une bonne solution dans ce genre de problème ? dans ce cas quel type d'architecture utiliser ?

Dans les mmo on voit souvent plusieurs "serveurs" ou l'on se connecte qui sont indépendants.
Je voyais la gestion d'un serveur de mmo comme cela :

Plusieurs petits serveurs logiciels qui prennent en charge chaque aspect du jeux mais qui tournent tous sur le meme serveur matériel.

- Serveur logiciel (processus donc) pour la prise en charge du tchat.
- Un autre pour la gestion des déplacements et des combats
- Un autre pour la gestion d'une base de donnée
(Dans ce cas commnent ils communiquent entre eux ?)

Ou alors es qu'en fait ce sont plusieurs serveurs mais qui sont cachés à l'utilisateur qui n'en voit qu'un seul .

Ou enfin tout est dans un seul processus qui tourne sur une seul machine. Dans ce cas comment les différents modules sont ils gérés , avec des threads ou encore un autre système peutêtre ?

J'espère qu'il y aura quelques membres du forum calé dans ce domaine, et je vous remercie d'avance pour vos réponses .

(je post ici car je développe en java)
06/07/2008, 23h03
divxdede

Salut,

Une architecture qui consiste à dédier un thread a chacun de tes clients ne peut pas te permettre de monter en charge serainement.

Si utiliser les Socket (java.io) est simple, pour un serveur imposant, tu devras te tourner vers des solutions utilisant des api non bloquante (java.nio)

Avec une api bloquante (java.io) on doit dédier un thread par client afin de pouvoir attendre l'arrivée d'un message.

L'avantage avec java.nio est de pouvoir mettre en pause un thread et qu'il soit reveillé dés qu'un événement arrive (quelque soit le client). Ce qui permet de faire la même chose qu'avec java.io mais avec beaucoup moins de threads.

Un serveur réalisé sur java.nio gérera mieux la montée en charge (nombre d'utilisateurs).

Il existe quelques librairies utilisant nio t'évitant de mettre profondément les moins dans nio.

Les plus répandues sont mina (apache), grizzly (sun).

Je développe également une API réseau utilisant nio : ObjectServer

Ensuite, selon le jeu que tu développes, tu dois reflechir à ton protocole de communication, voir si plusieurs canaux sont nécessaires.

Par exemple un canal en UDP pour l'échange de données "volatile" comme la position des joueurs et un canal en TCP pour l'échange de données plus stricte.

Ensuite tu as des algorithmes coté client qui peuvent "lisser" les défauts d'une communications. Dans le cas d'un échange UDP pour les positions des joueurs, il se peut qu'à un moment ou à un autre les messages soient perdus.

Si le client arrive à extrapoler les mouvements des autres joueurs par rapport aux dernieres informations connues, le client pourra continuer de donner un "mouvement" aux autres joueurs. Lorsque le client recevra les nouvelles données, il n'aura plus qu'a apporter la correction nécessaire par rapport a son extrapolation.

Bref, tout ca pour dire qu'il y a plusieurs facettes pour économiser un serveur.

Séb.
07/07/2008, 02h39
Richard Cypher

Donc avant tout utiliser la "nouvelle"(pas récente finalement^^) api d' entré sortie pour avoir de meilleur performance , ok.

Pour toi il faut quand même utiliser des threads , mais en restreindre leurs nombres , et éviter d'en créer et de les détruire à tout va pour économiser les resssources.

Donc faire une gestion fine des threads , mais ca veux dire combien de threads ? un par coeur physique /virtuel du processeurs ?
En gros si le pc a un double proc quadri-coeurs avec l'hyperthreading , se limiter à 16 threads ?

Es qu'il y des exemples de shéma qui explique comment bien concevoir un seveur avec java.nio (on sait jamais ^^). En gros je vois pas comment il faut que se soit organisé.

Si tu entends par canal uniquement un protocol différent , je pense que je n'utiliserai pas udp , j'ai besoin que les informations envoyées soit fiable a 100%. Enfin a première vue , je verai plus udp utilisé dans un fps.

Pour "mon jeu" , enfin pour l'instant yen a pas je réfléchis plus sur la conception technique de ce genre de produit , le mien s'apparente plus a un jeu de type wow. Donc pas forcement une latence extrêmement basse , mais surtout une fiabilité dans la communication , que si le joueur clic sur une attaque puis ensuite sur une autre que l'ordre soit bien respecté. Et meme pour les déplacements je pense qu'il veut mieux que ce soit fiable , mais c'est vrai que cela demande réflexion.

Je vois dans ton api , que tu donnes la possibilité d' envoi par le réseau d' objets java. Je me dit que c'est surement pas une option que je devrais utiliser pour ce genre de jeux non ? Ca ferait surement chuter les performances ?

En parlant de "coûts" , la compression avec gzip , ou des communications avec ssl c'est viable pour un serveur de ce type ?
En gros gzip permet de réduire la bande passante utiliser mais en contrepartie un cout supplémentaire en cpu . Et ssl sécurité accru mais plus de temps cpu utilisé ainsi que de bande passante. Qu'es tu en penses ?

Sinon pour en revenir au découpage en plusieurs modules du serveur . Ca me semble une bonne idée ? ( le tchat , les combats/deplacements , un module qui met a jour les fichiers/ou une bdd, ect ... ).

Mais comment tu organiserais ca toi ? Pour que le serveur arrive à transmettre les messages aux joueurs qui communiquent entre eux , tout en faisant les calculs pour les combats, prendre en compte le déplacement des joueurs , prévenir les autres joueurs du changement de position d'un joueur et mettre à jour les données du jeu dans la bdd sans que le serveur s'effondre.

Pas dans le détail , mais plutôt comment organiser tout ces aspects/modules dans leur globalité ?

Merci encore pour ta réponse.
07/07/2008, 11h16
millie

Citation:

Envoyé par Richard Cypher

Donc faire une gestion fine des threads , mais ca veux dire combien de threads ? un par coeur physique /virtuel du processeurs ?
En gros si le pc a un double proc quadri-coeurs avec l'hyperthreading , se limiter à 16 threads ?

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.
07/07/2008, 19h05
Richard Cypher

Citation:

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?
07/07/2008, 19h20
wiztricks

Citation:

Envoyé par millie

Il ne faut pas oublier que normalement, la plupart des threads seront endormis. Il faut voir en fonction des traitement effectués => s'il y a beaucoup d'acquisition de ressources (lock, lecture bloquantes...), les threads passeront leur temps à dormir du coup tu peux augmenter leur nombre.

S'il y a de la contention, il ne sert à rien d'augmenter le nombre de threads.
L'ideal est d'avoir la possibilité d'effectuer le plus grand nombre de traitement possible en parallèle et de pouvoir utiliser la capacité CPU/IO en modulant le nombre de threads crées. (c'est ici qu'on retrouve peut être la définition d'un pool de threads).
- W
07/07/2008, 19h23
wiztricks

Citation:

Envoyé par Richard Cypher

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?

Sans parler d'ideal, pour profiter de tous les processeurs il faudra au moins un nombre équivalent de processus ou de threads "actifs".
"actifs" = qui consomment du CPU (intelligement s'entend). Leur nombre est inférieur ou égal à celui des threads ou des processus existants/crées dans le système.
07/07/2008, 19h24
divxdede

Citation:

Envoyé par Richard Cypher

D'accord , mais dans l'idéal ce serait d'avoir toujours un nombre de thread actif égal au nombres de coeurs physique ou virtuel de la machine ?

Pas vraiment, tu peu avoir plus de thread actif que de coeurs.
L'objectif étant de pouvoir développer tes process indépendant pouvant être effectué en //
Ensuite que ton serveur puisse rééllement les traités en // ou si il doit scheduler tes threads pour pouvoir les servir tous ce n'est qu'un détails.

Il n'est pas rare qu'un serveur d'application dispose de plusieurs centaines de threads.

L'envoi d'objet java sur le réseau n'est qu'une vue lors de la conception.
Ce que mon api impose c'est de pouvoir convertir un "message réseau" en un objet Java et inversement.

Par défaut ObjectServer utilise la sérialisation/déserialisation pour y arriver.

Mais tu peu trés bien re-définir ce processus.

Par exemple écrire une interface comme suit
Code:

1 2 3 4 5 6 7 public interface MMOServerMessage { public byte[] encode(); public void restore( byte[] data ); }
avec par exemple une classe comme suit:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 public class PositionJoueur implements MMOServerMessage { .... /** Une position d'un joueur tient en 9 octets * 'p[idjoueur][x][y][z]' */ public byte[] encode() { byte[] result = new byte[9]; result[0] = 'p'; // Message 'Position' writeShort(result , 1 , getJoueur().getId() ); writeShort(result , 3 , getX() ); writeShort(result , 5 , getY() ); writeShort(result , 7 , getZ() ); return result; } private static void writeShort( byte[] buffer , int offset , short value ) { buffer[offset] = ((value >>> 8) & 0xFF); buffer[offset+1] = ((v >>> 0) & 0xFF); } public void restore( byte[] buffer ) { .... } }
Il reste ensuite à écrire l'ObjectStreamFactory permettant d'obtenir des ObjectOutputStream donnant ta propre implémentation de ObjectOutputStream (nottament utilisant writeObjectOverride)

L'idée principale est de pouvoir construire ton serveur en manipulant les messages sous forme d'objets JAVA sans te soucier de la facon ils sont transportés. Ignorer la forme "réseau" pendant le processus de développement rends ainsi ton code plus simple, robuste et facile à maintenir.

Ne pas passer par la sérialisation standard est effectivement une bonne chose si les performances sont critiques car la serialisation est un mécanisme lent.

Tout ca pour dire que mon API n'est pas incompatible avec ce point là.
Par contre elle est pour moi vis à vis du transport UDP qui reste d'aprés moi un moyen efficace d'échanger tout un ensemble d'information.

Et ca mon API ne sait pas le gérer l'UDP car ce n'est pas dans son périmetre de fonctionnalité (échanger des objets java ==> transferts fiables ==> TCP ), par contre des API comme Mina le savent trés bien.

Voila, j'espere t'avoir éclairer un peu.
PS: si tu veux découvrir un peu java.nio, tu peu regarder le code source d'ObjectServer qui peut être une entrée en matière.

07/07/2008, 19h42
wiztricks

Bonsoir,
Associer 1 thread à un client reste jouable lorsque le nombre de clients reste raisonnable. Pour le cas général, il faut essayer de dissocier le nombre de clients, requêtes,... des ressources qui vont être utilisées pour les gérer.

Cette "dissociation" à des impacts sur le design du code.
1 thread = 1 client, tout le contexte du client est "dans la thread".
M threads = N clients ou X requêtes, cela signifie des données partagées, de la synchronisation et donc d'autres soucis côté "scalabilité".

Plus généralement, il faudrait que vous puissiez remettre à plat les différents traitements pour voir quelles sont les données à synchroniser et quel niveau de parallèlisme pourrait être atteint.

Dans les propriétés de la solution idéale vous ne devriez pas vous restreindre à faire tourner des threads sur un multiprocesseur mais rendre aussi possible l'exécution d'un certain nombre d'activités sur des boitiers différents.

Une fois ce design validé, il sera temps de trouver les technologies qui permettront de le réaliser.
Cordialement,
- W
11/07/2008, 14h43
nouknouk

salut,

beaucoup de choses pertinentes ont déjà été dites, je me permets donc juste de rajouter mon petit grain de sel sur certains points précis:

Citation:

Je vois dans ton api , que tu donnes la possibilité d' envoi par le réseau d' objets java. Je me dit que c'est surement pas une option que je devrais utiliser pour ce genre de jeux non ? Ca ferait surement chuter les performances ?

Pour moi, tu as deux extrêmes:

- une API réseau très haut niveau qui va te permettre d'envoyer des objets complets (genre RMI, CORBA, ...). Avantages: plus simple à coder, plus clair car plus haut niveau et donc moins sujet aux bugs. Inconvénient: perfs en termes d'utilisation CPU et en bande passante réseau.

- un API très bas niveau ou limite chaque partie de ton programme va aller écrire directement sur la socket pour envoyer son petit paquet qu'elle aura sérialisé par ses soins. Avantages: bande passante réseau peut être optimisée (car implémentation au 'cas par cas'), perfs. Inconvénient: devient très vite ingérable et très peu résistant à l'évolutivité.

Après à toi de trouver le juste milieu. Mon expérience personnelle (qui n'engage que moi donc) tend à me faire adopter une API relativement bas niveau, qui restera simple et efficace niveau perfs, mais sans tomber dans les extrêmes. En gros, techniquement:
- s'assurer d'avoir un mécanisme commun pour sérialiser / désérialiser efficacement uniquement les types les plus simples (int, float, String).
- avoir un protocole commun (genre un paquet de données = un header de x bytes pour la taille du paquet, y bytes pour l'ID du 'canal' de communication, puis les données utiles).
- séparer les échanges par canaux de communication (^^) pour un découpement logique (canal 1 = chat, canal 2 = ...).

Citation:

En parlant de "coûts" , la compression avec gzip , ou des communications avec ssl c'est viable pour un serveur de ce type ?
En gros gzip permet de réduire la bande passante utiliser mais en contrepartie un cout supplémentaire en cpu . Et ssl sécurité accru mais plus de temps cpu utilisé ainsi que de bande passante. Qu'es tu en penses ?

Pour moi, gzip va te demander trop de ressources. Mieux vaut ne rien compresser. Et ce d'autant plus que le coût de la bande passante n'est plus si exhorbitant maintenant.
SSL, deux choses:
- non, ça n'augmentera pas la sécurité si tu penses à la possibilité de 'hacker' ton protocole de communication pour implémenter un 'bot' (ie. faux client qui simulera le comportement d'un vrai joueur). Ca augmentera à peine la difficulté pour ton hackeur. Comme toujours, il faut toujours partir du principe que c'est le serveur qui contrôle tout en permanence et il ne faut jamais faire confiance au client.
- question performances, il me semble (?) que certains processeurs sont capable d'encrypter/décrypter au niveau matériel, donc dans certains cas il se peut que ça ne tue pas les perfs. Dans le cas contraire, même souci que GZip.

Citation:

Sinon pour en revenir au découpage en plusieurs modules du serveur . Ca me semble une bonne idée ? ( le tchat , les combats/deplacements , un module qui met a jour les fichiers/ou une bdd, ect ... ).

Il y a plusieurs découpages possibles:
- par grosse fonctionnalité du serveur (BDD, tchat, ...): oui, ça me semble intéressant, 'efficace' niveau design. Problème: bien identifier chacune des parties pour le découpage afin de s'assurer que les interactions entre chaque gros bloc seront les plus faibles possibles.

- par pool de client: un MMO est censé par essence avoir un nombre très important de clients. Jamais un unique serveur ne peut gérer ça tout seul. Il faut des grappes de serveurs qui chacune s'occupent de x clients. C'est très lourd à mettre en place car il faut synchroniser tous les serveurs entre eux. Mais dans un premier temps, ce ne sera pas nécessaire, à moins que tu ne développes pour Blizzard ;)

Ceci étant dit, un serveur qui tient 3000 ou 4000 connexions n'est pas à proprement parler un gros serveur. Une architecture simple, mono-threadée (avec NIO) suffira amplement pour supporter la charge. Donc si tu n'en n'as pas réellement besoin au début, abstiens-toi.
Le moment venu, si ton concept marche effectivement bien et que ton architecture n'arrive plus à suivre, il sera toujours temps d'évoluer petit à petit.
A mon avis pour toi, l'important à l'heure actuelle ést de garder une architecture à peu près propre, sans y sacrifier une surcharge de travail non plus) pour accélérer les modifications si un jour elles deviennent nécessaire.

Pas plus. Car tout le temps que tu passeras là-dessus (qui sera inutile au départ) tu ne le passeras pas sur autre chose (et on ne compte plus depuis bien longtemps les projets (en particulier les MMO) trop ambitieux au départ et qui n'ont jamais vu le jour au final). Mieux vaut viser (très) petit et avancer fonctionnalité par fonctionnalité

My 2 cents.