vendredi 12 avril 2013

HB Monthly Update #50 : la cinquantième Monthly !

Posté par Olah Le vendredi 12 avril 2013 à 22:23
Salut à tous les humains et autres reptiliens, nous sommes le 12 et comme chaque mois, c'est le jour de la Monthly! (oui nous sommes toujours le 12!) Mech et Nigel n'ayant pas la possibilité de faire cette Monthly, il est de mon devoir de vous en faire profiter, même si certains ont perdu la foi dans notre noble quête et ose, sur ce propre forum, faire part de leurs doutes ... Honte à eux! Si les lois Française et Suisse ne me l'interdisaient pas, je les pendrais sur un bûcher! Maintenant, place à la question que tout le monde ce pose:

Comment que le bouzin k’i marche ?


Aujourd’hui, nous nous faisons fort de répondre à cette simple question posée dans le titre. Comment marche le jeu ? Et nous ne parlons pas du code, mais de ce qu’il y a derrière : les serveurs !

Rappel : Un serveur fonctionne en permanence, répondant automatiquement à des requêtes provenant d'autres dispositifs informatiques (les clients), selon le principe dit client-serveur.

Halo-Battle repose sur trois systèmes :
- le PHP
- MySQL
- Java



Le Java met à jour en temps-réel la base de donnée (MySQL). Cette base de donnée contient toute les informations du jeu : nombre de vaisseaux, richesse, nom du joueur... Le PHP vas chercher ces informations pour les afficher sur votre navigateur (this is where the magic append). Le problème est que le serveur à une capacité limitée. Tout comme votre PC ne peut (peut-être) pas faire tourner Battlefield 3 (TM), un serveur lambda ne peut pas gérer toutes les personnes se connectant à Facebook (TM). Aucun serveur en fait :p Le problème se pose donc. Nous pouvons optimiser autant que nous le voulons (voir quelques monthlys plus haut), les serveurs peuvent-ils tenir la charge ?

Il faut savoir que chacune de vos actions sur une page web en php génère de la charge sur le serveur car oui, c’est le serveur qui traite vos demandes. Ensuite, il y a aussi de la charge avec MySQL puisqu’il fournit les informations dont php à besoin pour afficher les bonnes informations et le java là-dedans qui travaille en permanence comme un acharné pour calculer la position de vos flottes, ce qu’elles peuvent durant un combat ou encore l’évolution de vos constructions et de vos ressources et puis s’occuper de 10 joueurs, c’est facile. Avec 2 000, c’est une autre histoire ... Surtout avec les idées débiles de Mech ...

Comment supporter autant de monde ?


Bref, le serveur de HB doit être en mesure de supporter tout ce petit monde et donc deux solutions se profilent :
- prendre un gros serveur qui va gérer les trois systèmes: c’est la solution la plus simple nous allons dire. Les trois éléments qui constituent le jeux sont présents dessus. L’avantage, c’est qu’il ne s’agit que d’une structure à maintenir et généralement, le goût global se révèle moins onéreux. Par contre, l’évolutivité est presque nul et il faut absolument que php, mysql et java cohabite ensemble (pas gagné)

- prendre trois petits serveur: soyons franc, c’est plus cher! Par contre, c’est le fantasme de Nigel donc il va falloir mettre la main à votre porte monnaie. Cette architecture est pleinement évolutive, déjà parce que chaque élément du site possède son propre serveur dont il n’utilise pas toujours la totalité des ressources, mais aussi parce qu’il suffit de remplacer le serveur défectueux s’il y a le moindre problème.

Pour le moment, nous n’avons pas de réponses précises. Nigel fait de nombreux benchmark pour savoir ce qui serait le mieux. Nous vous tenons informé dès que nous en savons plus

Et voilà ... à dans un mois

PS de Nigel et Mech: plus d'information pour le 31 Avril.

PS n°2 de Mech: Vous avez failli avoir une magnifique Monthly sur les chats, heureusement que d'autres sont là ...

PS n°3: Parce que l'équipe de développement aime vous taquiner, je vous rappelle que le mois d'Avril ne comporte que 30 jours.

PS n°4: Le chocolat c'est bon :3