La programmation réseau, Performance ?

Le problème exposé dans ce sujet a été résolu.

Peux-tu préciser ce que tu appelles « besoin de performances » (et probablement aussi ce que tu entends par « programmation réseau (axé serveur de jeu ») ?

Sans ça, il va être difficile de te faire une réponse pertinente.

PS : tu trouveras des informations sur la programmation de serveurs de jeux dans ce topic.

Bonjour, Nouveau-Multi-De-Absolute.

Je vais faire l’effort de répondre un poil sérieusement :

Non, sauf cas très particulier.

Ce qui limite un serveur en général ce sont ses IO, et les IO seront toujours les mêmes quel que soit le langage que tu utilises. Bref, peu importe le langage utilisé, ce style de logiciel demande surtout de concevoir ton programme correctement pour le faire passer à l’échelle.

PS : Je te remercie d’avoir confirmé ton identité. La prochaine fois je t’appellerai par ton prénom. :)

+4 -0

Si tu pouvais par contre ce genre de réflexion ^^

Je vais faire l’effort de répondre un poil sérieusement 

Praemix

J’éviterai ce genre de réflexion quand tu arrêteras de créer un nouveau compte chaque fois que l’envie te prend de créer un topic à troll sur les performances des langages, en faisant une fixation sur la garbage collection qui ne trompe plus personne sur ce forum.

+3 -0

Besoin de performance : Un besoin en performance que des langages à GC ne pourrait pas fournir

Programmation réseau axé serveur de jeu : Programmation de serveur de jeu

Praemix

Allez, pour la beauté du geste, je vais aussi faire l’effort de répondre sérieusement. En admettant qu’un serveur de jeu ait besoin de performance, déjà il faut savoir ce qu’on appelle performance dans un cadre client-serveur très chargé. En particulier, il faut généralement déterminer si, à matériel égal :

  1. On veut servir un maximum de clients – quitte à dégrader les temps de réponse,
  2. On veut garantir des temps de réponse optimaux, quitte à envoyer balader des clients.

(On est dans le cadre d’un compromis de performances, servir le maximum de clients tout en garantissant des bons temps de réponse est impossible).

Généralement un serveur de jeu veut la solution 2. Il faut donc trouver une solution d’implémentation qui gère les clients en trop le serveur sans pénaliser les temps de réponse (j’ai un très bon exemple du système inverse, c’est le serveur Java EE d’IBM : il a un tas de mécanismes de protections et de files d’attentes qui font qu’il est raisonnablement improbable d’arriver dans un état où le serveur refusera de traiter une requête, même si les temps de réponse atteignent plusieurs minutes ; par contre il est tout autant impossible d’avoir une requête servie en moins de 100 ms).

Note que tout ça c’est une question d’implémentation, donc d’algorithmique et de compromis processeur / mémoire / entrées-sorties ; et que comme le disait nohar ci-dessus, très généralement en programmation réseau, c’est les entrées-sorties qui limitent les performances (en supposant un programme correctement codé).

Quant à ta fixation sur les garbage collector : c’est en fait très rare que le langage lui-même pose un problème de performance, et encore plus rare que n’importe quel langage à GC soit trop lent à cause du GC.

D’expérience, un programme qui ne fait pas ce qu’on veut en un temps raisonnable, c’est dans 99 % des cas l’un de ces problèmes :

  • Ce qu’on lui demande est physiquement impossible dans le temps raisonnable (dédicace à ce collègue qui espérait voir une requête avec une triple jointure cartésienne sur 3 * 5 000 000 ligne aboutir un jour (ça aurait nécessité le traitement de 1.25 x 1020 lignes)
  • Le compromis processeur/mémoire/entrées-sorties est mauvais, il faut réécrire l’algorithme avec un autre compromis pour épargner la ressource limitante
  • Le programme est tout simplement pas optimisé du tout et on peut l’améliorer d’un facteur 10 en une demi-journée de travail

(Je passe sur les demandes d’optimisations inutiles).

Si jamais par miracle tu arrives à prouver, analyse du programme et métrique à l’appui, que ton programme est lent et algorithmiquement optimal, dans la grande majorité des cas il suffit de le faire tourner sur un plus gros matériel pour que ça marche. Parce que les langages de programmation, même à GC, qui sont orientés « performances » ont un compilateur « Just-In-Time » qui te donnent déjà des performances tout à fait honorables, et pour lesquelles il va être difficile de faire significativement mieux juste en changeant de langage. Je te renvoie vers ce billet et cet autre billet pour des exemples. Si ce sont les pauses dûes aux GC qui te font peur, un GC bien conçu a des réglages pour prendre ce problème en compte.

Donc, si tu as réellement un problème de langage qui nécessite absolument un langage sans GC, c’est que tu remplis toutes ces conditions :

  • Tu as une équipe d’ingénieurs/chercheurs assez doués pour te créer un programme algorithmiquement optimisé,
  • Ton programme a une contrainte ultra-forte et permanente sur les latences ; ou il est tellement consommateur en RAM que la surcharge RAM imposée par les GC n’est pas gérable juste en ajoutant des barrettes de mémoire,
  • Tu es déjà sur du matériel tellement cher que c’est rentable de payer des gens à (ré)implémenter ton programme dans un langage spécifique juste pour des raisons de performances.

En gros, si tu en est à ce niveau de contraintes, c’est que tu es une entreprise ou une institution qui sait ce qu’elle fait. Et donc tu ne poses pas la question sur ZdS (ou du moins tu n’en fais pas un critère de choix).

PS : Tu as supprimé ton compte, c’est ton choix. Pense à supprimer tes 8 autres multis aussi…

Bref, je n’ai pas ma place sur ce forum

anonyme

En fait, toi, si (sinon on aurait déjà banni tous tes multis), mais pas ce comportement.

C’est quand même dingue de se cacher et de ne pas assumer ses propos sur un forum sur lequel on tolère ce genre de threads trollogènes.

+4 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte