Bonjour,
Je suis en train de mettre en place l’infrastructure pour commencer dans la prochaine version le supports des clusters.
L’overhead (qui est assez couteux sur http1) de la couche Ssl est peu important sur un serveur de type MMORPG car il garde la connexion ouverte. Par contre, à cause des petits packets envoyé à intervalle éloigné (ont de peu donc pas les grouper), la couche Ssl deviens extrêmement lourde. Le ralentissement vis à vis d’une connexion en claire est de 24x sur un Intel haswell (avec prise en charge matériel).
Les syscall pour les events des trames réseaux sont trés correcte et ont un coût minimum car il sont multipléxé sur epoll avec linux. Ca semble un peu du bricolage pour les timers, … je veux même pas voir d’autre syscall… Par contre une lecture/écriture sur un socket = un syscall, ce qui peu devenir très lourd rapidement. Une suggestion sur le problème C10M est de by-passer le noyau, cela oblige de ré-implémenté TCP, c’est trop dangereux et dur pour être fait (hors mit cas spéciaux). Par contre un syscall pour multipléxé les entrées/sorties sur socket peu être utile.
Comment bien découper votre serveur pour avoir un cluster de serveur? Déjà il faut l’avoir bien optimisé pour maximiser le ratio utilisateur par serveur/nombre de serveur. Car le mode cluster à un cout. Ensuite balancer via un round-robin dns sur plusieurs frontaux (cela permet de s’affranchir de HAPROXY, ou tout autre système qui serai à notre charge et moins fiable). Hors mit les clients, les frontaux doivent avoir le minimum de connexion, alors n’utilisez pas de maillage, mais une structure de serveur en arbre. Dans le cas de CatchChallenger cela vas être une connexion pour la base de données, et une connexion pour un serveur racine (chargé de broadcast, ou de passé le client sur un autre serveur via reconnexion pour séparer les serveurs: une groupe de serveurs = un groupe de maps dans la même zone). La découpe vas influer fortement sur votre cluster, spamer des threads dans tout les sens et n’importe comment vas ralentir votre serveur (apache worker vs nginx/lighttpd). Je vous conseiller d’attaquer votre db en asynchrone, et qu’elle ai plusieurs frontaux. Vous pouvez coder la communication inter-serveurs en claire, et faire des tunnels de communications crypté via openssl pour sécurisé l’échange. Cela permet un maximum de performance sur un réseau de confiance, et de la sécurité sur internet.
Ssl fourni une compression activé par défaut. Je trouve cela assez mauvais, car la compression devrai être séparé de la cryptographie. Pour une question de sécurité, mais aussi de fléxibilité: toutes les formes de compression ne sont pas disponible (xz), et certain protocole comme CatchChallenger à sa propre compression adaptative interne qui est bien plus efficace. La compression devrai être donc si disponible, désactivé par défaut (bien que mon opinion n’est pas tranché sur ce point). La compression, même gzip/zlib doit avoir au moins 100 octets pour être efficace, hors la grosse majorité des packets de CatchChallenger fait moins de 6 octets. Et le reste est compressé…
J’espère vous avoir aidé.
