Le framework web le plus rapide au monde est écrit en Java selon un test de performance de TechEmpower

Si Java est considéré par plusieurs professionnels comme étant lent et lourd,
le framework web le plus rapide au monde est écrit en Java selon un test de performance de TechEmpower

TechEmpower a publié les résultats d’un test de performance de cent soixante-deux plateformes d’applications web, de framework et de microframeworks écrits dans différents langages de programmation, dont Java, C++, Go, Python ou encore Ruby. Ces résultats mettent en évidence la suprématie de Java par rapport aux autres langages utilisés pour écrire les différentes plateformes en termes de rapidité. En effet, d’après les résultats de TechEmpower, le framework rapidoid écrit en Java affiche une performance de 100 % dans les résultats du test de performance en termes de rapidité, contre 99,6 % pour le framework cpoll_cppsp écrit en C++ ou encore 89,9 % pour le framework fasthttp_postgresql écrit avec le langage Go. La figure suivante est un extrait du résultat du test de performance publié par TechEmpower.

Pièce jointe 205120

Java est souvent présenté par certains programmeurs web et autres experts du génie logiciel comme étant un langage lent et assez lourd par rapport aux autres langages du web. Cependant, ces résultats du test de performance de TechEmpower viennent prouver le contraire. Les lenteurs de Java sur certaines applications ne sont pas forcément dues à un défaut de performance du langage lui-même, mais des fois parce que les bonnes pratiques de programmation ne sont pas respectées par les développeurs, affirme un expert en génie logiciel. Selon lui, ceux qui prétendent que Java est langage lent et lourd se basent sur des considérations des années quatre-vingt-dix pour juger le langage. Il ajoute que le langage Java moderne n’a rien à envier aux autres langages de programmation en termes de rapidité.

Source : TechEmpower

Et vous ?

:fleche: Que pensez-vous de ce test de performance de TechEmpower ?

Voir aussi

:fleche: le forum Langages de programmation

Java s'est clairement amélioré niveau performances et légèreté. Désormais, comme tout bon langage de programmation,les résultats sont plutôt liés à son mode d'utilisation. La lenteur de Java vient surtout d'éléments mal implémentés voire peu utiles, mais rarement incontournables. Quelques guides d'optimisation.

http://blog.jooq.org/2015/02/05/top-...tions-in-java/
http://java-performance.com/

Par contre, Java en lui même reste en retrait question sécurité. Donc il demande plus de précautions au niveau du déploiement et de l'analyse de code.

Quand à son mode d'utilisation et son écosystème, je le trouve plus lourd et moins agréable que .NET.

Oh là, wait, c'est quoi ces chiffres ? Il 'agit pas juste de dire "oh y'a un framework en Java qui arrive N°1 dans une table" et d'en faire un article. Faut creuser, sinon c'est pas la peine : j'arrive pas à trouver de description des critères utilisés, donc ça veut dire quoi tout ça ? Quand je parcours les tables, si j'ai bien compris, ils ont fait des requêtes pour fournir une page "plaintext"... Il est où l'intérêt du framework web si c'est pour fournir un fichier texte sur lequel il n'y a aucun traitement à faire ? Qui plus est, le benchmark semble être fait en demandant, pour chaque framework, un fichier de 256/1024/4096/16384 octets, de regarder combien il en fourni par seconde, et de prendre le meilleur résultat... donc on compare des résultats sur des fichiers de tailles différentes dans cette liste, autant dire que ça n'a pas beaucoup de sens. Qui plus est, les résultats peuvent changer pas mal pour certains frameworks, alors que pour d'autres ça reste relativement constant (comme pour le n°1), cette constance venant confirmer qu'on traite là des fichiers dont finalement le framework n'a rien à faire.

Donc j'ai beau être un grand amateur de Java, faut rester honnête : cette analyse ne confirme absolument pas ce que l'article affirme, autrement faut me montrer où je me plante en me donnant les explications du benchmark.

Et en regardant bien, il semble qu'il y ait aussi des fonctionnalités ignorées sous prétexte que d'autres n'en on pas... donc question valeur pratique, tu repasseras.
https://www.techempower.com/benchmar...ak&test=update

Edit: En regardant bien, il semble que ce ne soit pas des octets mais des accès concurrents. Néanmoins on reste dans le vague de manière générale et sur du plaintext toujours. Si on regarde le traitement JSON, le n°1 devient n°2 avec une différence significative, le premier étant fait en C.

Le test où rapidoid se retrouve 1er est basé sur un simple Hello World !
Les autres tests semblent un peu plus réaliste et Java n'arrive pas toujours 1er.

J'adore Java, Java peut-être très performant, lorsqu'il est utilisé avec des petits frameworks comme Vert.x, dropwizard ou autre.
Pour du front, NodeJS avec d'autres framework excel aussi.
Python et Ruby avec leurs frameworks peuvent être très bon, tout comme Go et Rust dans tout ce qui est concurrence et distribué.

Chaque langage/plateforme/framework a ses forces et faiblesses, le tout est de les connaitre.
C'est pour cela que je trouve que la "stratégie" micro-service très bonne.
Je trouve juste dommage qu'on nous parle d'expert en langage X, et que certaine entreprise oblige d'utiliser la stack Y.
Pour moi, les développeurs sont largement capables de choisir leurs stacks, leurs environnements et de le maitriser avec un peu de pratique.
Il faut savoir tester de nouvelles choses, itérer, et déployer. Et si il est possible d'avoir quelqu'un qui connait la stack que l'on est entrain d'utiliser => pair programming, ou alors de s'y former => R&D.

Java peut-être très performant, Cassandra et ActiveMQ sont des bons exemples.
Les langages fondé sur la JVM fonctionne très bien aussi avec des projets très performant comme Kafka, Spark, Akka, Play.

Citation:

---

Envoyé par Victor Vincent

Si Java est considéré par plusieurs professionnels comme étant ...

---

Traduction : on a aucune étude sérieuse à ce sujet.

Citation:

---

Envoyé par Victor Vincent

le framework web le plus rapide au monde est écrit en Java selon un test de performance de TechEmpower

---

Effectivement, un framework java arrive en premier sur 1 test de performance. Et sur les 5 autres tests de performance de "l'étude", ce sont des frameworks en d'autres langages.

Je suis du même avis que les remarques précédentes : d'une étude dont on ne sait pas grand chose, qui comporte cependant plusieurs tests mais l'article cible qu'un seul des tests (le plus simple en plus de type "Hello World") et en tire une conclusion hâtive...

Une petite remarque pour ValCapri : attention à l'orthographe car ça peut changer la signification...

Citation:

---

Envoyé par ValCapri

Pour du front, NodeJS avec d'autres framework excel aussi.

---

=> il est possible de faire des choses avec Excel mais je pense que tu voulais dire que "NodeJS avec d'autres frameworks excelle aussi" ;)

Question objectivité on repassera...

Le plus lent avec java c'est surtout le lancement de la JVM.
Après clairement en exécution c'est super rapide java.

Après "le framework le plus rapide du monde" c'est un titre aguichant, mais il y a quoi derrière ?
Je veux dire, par exemple avec django, en une demi journée je te fais une application web qui fait quelque chose, et avec nginx en frontal ça marche bien.

Si tu as une page instantanément mais qu'il te faut 3 ans pour créer une application, quel intérêt?

En plus rapidoid ne supporte même pas les websockets. On est en 2016 les mecs hein?!

Bref, je vous le laisse bien volontiers votre framework "le plus rapide du monde!".

post a troll

Je pensais qu'on disait que Java côté serveur était lourd et lent à cause de la stack d'outil qu'on empilait côté serveur.

Il est possible que l'on retire cet article de la section News ?
Car la on dirait à de la publicité déguisé avec des conclusion largement fausses basé sur les tests d'une étude comparant plein de framework hors celui cité n'est présent que dans 2 test sur les 6.
De plus sur l'autre test(la sérialisation JSON) il n'est que 2ème

Sinon voila le dépôt git des tests -> https://github.com/TechEmpower/FrameworkBenchmarks
comme ça vous pourrez faire vos tests

Je croyais que les débats ça servait aussi à démonter les trucs bidons, non ?
Si tu ne fait que des news simplistes sans risques ni doutes ou tu affiche 2+2 = 4 ou est le débat ? :koi:

J'ai regardé ces tests à ses débuts il y a plusieurs années et il y a une chose qui m'avait frappée, je sais pas si elle est encore d'actualité mais je la précise quand même:

Certains benchs sur des frameworks full stack (grail, play, ninja) comprenaient des accès à la DB faits avec des outils tels que hibernate, JPA ou Ebean, avaient aussi des mécanismes avancés comme le mapping auto des paramètres de requête dans les controllers suivant le Content-Type etc... et ceci était comparé à des autres frameworks qui étaient à peine plus que de la Servlet avec du JDBC bare metal.
Donc au bout d'un moment la comparaison a plus beaucoup de sens si on compare des mastodontes full-stack avec des trucs très bas niveau qui font 50x fois moins de choses? C'est comme si j'allais jeter un <?php echo 'hello world' ?> dans un fichier à la racine d'un serveur et conclure que symphony est pas performant à côté?

Citation:

---

Envoyé par LSMetag

Par contre, Java en lui même reste en retrait question sécurité. Donc il demande plus de précautions au niveau du déploiement et de l'analyse de code.

---

Je pourrais savoir sur quoi on se base pour arriver à cette conclusion? Parce que j'ai l'impression que les gens qui tiennent ce genre de propos mélangent en fait les applets ou les plugins java pour navigateur qui sont en fait des technologies d'exécution desktop, avec du java web ou tout se passe côté serveur ce qui n'a au final pas grand chose à voir.

Si java est si rapide, pourquoi on n'utilise pas ce langage en trading HAUTE FRÉQUENCE?;)

Citation:

---

Envoyé par _skip

Je pourrais savoir sur quoi on se base pour arriver à cette conclusion? Parce que j'ai l'impression que les gens qui tiennent ce genre de propos mélangent en fait les applets ou les plugins java pour navigateur qui sont en fait des technologies d'exécution desktop, avec du java web ou tout se passe côté serveur ce qui n'a au final pas grand chose à voir.

---

Je parle en effet plutôt du Desktop, mais "connecté" via par exemple des services web ou des communications autres. Dans ces cas-là, on peut véroler tout un éco-système. En tout cas, il y a des raisons à la quasi interdiction de Java par les navigateurs internet et au déferlement de news de failles de sécurité depuis la reprise par Oracle.

Citation:

---

Envoyé par moueza

Si java est si rapide, pourquoi on n'utilise pas ce langage en trading HAUTE FRÉQUENCE?;)

---

Bonne remarque. On l'utilise pour ça (petite recherche rapide). Le trading "haute fréquence" n'est en passant pas si rapide, en tout cas nettement moins que ce qu'on attend de la plupart des languages.

Citation:

---

Envoyé par LSMetag

Je parle en effet plutôt du Desktop, mais "connecté" via par exemple des services web ou des communications autres. Dans ces cas-là, on peut véroler tout un éco-système. En tout cas, il y a des raisons à la quasi interdiction de Java par les navigateurs internet et au déferlement de news de failles de sécurité depuis la reprise par Oracle.

---

Bien sûr mais je doute que ce soit un véritable problème hors des navigateurs. Dans un environnement desktop, c'est beaucoup une histoire de confiance, tu lances pas un programme en lequel tu n'as pas confiance, et encore moins s'il te demande à priori sans raisons des privilèges élevés, mais ce n'est pas propre à java. Sur le plan de l'accès à des services distants, tu disposes des mêmes moyens que n'importe quel language pour sécuriser les échanges, c'est plus une histoire des protocoles de communications utilisés mais java ne te force pas d'utiliser des choses non-sécurisées.

En revanche, à compter du moment où java propose un plugin d'exécution pour navigateur disposant d'un mode "sandbox" et que malgré cela des applications arrivent à sortir du bac à sable pour intervenir sur le système de l'utilisateur, là c'est clair c'est un sacré problème. Ces technologies sont vieillissantes, elles sont apparues dans un contexte ou on avait du activeX, du flash, même des espèces de sous-produits de toute sorte à l'age de pierre des RIA. Et elles se sont certainement très mal adaptées. Mais je reste quand même convaincu que les problèmes de sécurités de java ne sont pas liés à java, mais aux applets ou éventuellement à JWS qui sont sans doute qu'un infime pourcentage des développements java actuels.

while true ; do nc -l 80 < index.html ; done

j'ai combien de 100% la ? :p

Citation:

---

Envoyé par Victor Vincent

Il ajoute que le langage Java moderne n’a rien à envier aux autres langages de programmation en termes de rapidité.

---

Sans blague ! Faut oser le dire. Java a ses points forts et ses points faibles comme n'importe quel langage.

Rapidité et ben parlons temps réel dur, jeux vidéos et HPC...

Citation:

---

Envoyé par _skip

Bien sûr mais je doute que ce soit un véritable problème hors des navigateurs. Dans un environnement desktop, c'est beaucoup une histoire de confiance, tu lances pas un programme en lequel tu n'as pas confiance, et encore moins s'il te demande à priori sans raisons des privilèges élevés, mais ce n'est pas propre à java. Sur le plan de l'accès à des services distants, tu disposes des mêmes moyens que n'importe quel language pour sécuriser les échanges, c'est plus une histoire des protocoles de communications utilisés mais java ne te force pas d'utiliser des choses non-sécurisées.

En revanche, à compter du moment où java propose un plugin d'exécution pour navigateur disposant d'un mode "sandbox" et que malgré cela des applications arrivent à sortir du bac à sable pour intervenir sur le système de l'utilisateur, là c'est clair c'est un sacré problème. Ces technologies sont vieillissantes, elles sont apparues dans un contexte ou on avait du activeX, du flash, même des espèces de sous-produits de toute sorte à l'age de pierre des RIA. Et elles se sont certainement très mal adaptées. Mais je reste quand même convaincu que les problèmes de sécurités de java ne sont pas liés à java, mais aux applets ou éventuellement à JWS qui sont sans doute qu'un infime pourcentage des développements java actuels.

---

Merci pour ces éclaircissements. En effet si mes souvenirs sont bons les failles consernaient principalement les Applets et JWS. Ce qui n'existe pas forcément ailleurs et peut biaiser l'opinion. Mon Java est plutôt ancien. Est-ce que des vulnérabilités au niveau des EJB, pour les communication inter-applications sur plusieurs sites pourraient avoir un impact ? En tout cas il est clair que de nos jours il faut éviter au maximum toute application externe au navigateur. Plutôt utiliser HTML5/WebGL/X3Dom au lieu d'un applet Java ou de Flash. Malheureusement les bonnes pratiques sont rarement respectées, pour des raisons de productivité en entreprise, ou de méconnaissance.

Microsoft a peut-être eu raison d'abandonner rapidement Silverlight (qui pour moi était meilleur que Flash). Il y avait en effet eu une faille dans la Sandbox.

Je me suis éloigné du sujet principal mais je n'avais pas fait attention au fait que ces Frameworks ne faisaient pas les mêmes choses et que donc ce bench n'était pas pertinent. Il vaut mieux bencher des morceaux de code similaire ou des frameworks similaires en matière de fonctionnalités (pour évaluer les différences sur chaque fonctionnalité).

Il y a un paradoxe chez moi. Oracle et Java sont reconnues comme technologies performantes et éprouvées. Et pourtant je les trouve lourdes à manipuler et poussives.
Peut-être est-ce dû à la machine virtuelle Java, qui est une aide à l'interropérabilité et l'utilisation sur tous les systèmes, mais aussi aux outils comme Eclipse que j'ai du mal à appréhender.

Je m'aperçois aussi que même si les syntaxes sont proches entre C# et Java, leur mode d'utilisation est différent. Une simple transposition de code peut entraîner de sacrés différences. Par exemple si l'appli utilise des expressions régulières, mal supportées par Java. Bref, il faut se limiter à des tests simples.