Envoyé par
JCB001
Après si on compare par rapport à la vitesse d'écriture et au plus faible nombre de bugs, à la sécurité du code, je pense que java est plus performant que C++...
Lorsqu'on parle des performances d'un langage, il s'agit d'un terme très précis qui désigne l'efficacité du code obtenu. Ou si tu préfères, la vitesse d'exécution.
Envoyé par
JCB001
De plus Java est surtout utilisé avec des serveurs JSP, où souvent le facteur limitant est la base de données et non le langage y accédant... donc c'est un faux problème.
Est-ce que tu as déjà réalisé un test de monté en charge d'un serveur Web ?
Il s'agit là d'une idée reçue complètement fausse.
Lorsque tu fais ton test de monté en charge, ce qui lache en premier en générale c'est la consommation CPU du serveur Web, et selon la façon dont l'appli est écrite, la consommation mémoire n'est pas très loin.
On peut améliorer la monté en charge en ajoutant d'autres serveurs Web en load-balancing. En revanche, une base de données ne se load-balance pas !
Si la base de données était le facteur limitant, il serait inutile d'ajouter des serveurs Web puisque la base serait déjà saturée avec un seul !
La base de données comme facteur limitant, c'est ce que pense les développeurs lorsqu'ils développent un traitement unitaire dans leur coin :
Un seul client qui solicite le système, on lance le traitement, et on regarde le temps de réponse unitaire, et on se rend compte qu'on passe le plus de temps dans l'exécution des requêtes faites sur la base.
Sauf qu'on utilise des caches pour ne pas avoir à refaire les mêmes requêtes sur la base.
De plus en générale, les requêtes sont triviales, la base de données met à peine quelques microsecondes pour calculer la requête. Et l'essentiel du temps de traitement se passe dans l'API d'accès à la base de données, sur le poste client ! Donc de la consommation CPU côté serveur Web (la trame réseau est décodée une première fois par le pilote natif du SGBD, puis elle est transformée, convertie, convertie encore... en remontant les 50 couches d'encapsulation des différentes API... est convertie encore dans les DAO de l'appli, voir par un ORM...).
Et lorsque ce n'est pas l'API cliente qui travaille, ce sont des temps d'attente liés pour l'essentiel à la latence du réseau.
Sur un serveur digne de ce nom, il n'y a pas qu'un seul client. Le serveur est multi-threadé, de sorte que les temps d'attentes précédents sont récupérés pour traiter un autre client pendant ce temps.
Globalement, lorsque la charge du serveur augmente (le nombre de clients simultanés augmente), les temps de réponses se dégradent lentement parce qu'il faut trouver des "trous" à récupérer pour servir tous les clients. La dégradation des performances est proportionnelle à la probabilité d'avoir une collision pour l'utilisation d'une ressource critique (le plus souvent, le CPU).
Jusqu'à ce qu'il n'y ait plus de trou à récupérer : On a atteind le point de saturation du serveur, et les temps de réponse s'écroulent d'un coup.
Si ton langage de développement est un gouffre à CPU (ou à mémoire), tu atteindras le point de saturation du serveur Web bien plus tôt...
D'ailleurs, lorsque
Facebook à fait HipHop pour convertir leur site PHP en C++, ils ont bien démontré l'importance des performances du langage.
1 |
0 |
Retrouvez l'annonce aux Scala Days 2011
) les codes sources : multi-language-bench 
