Open source et architecture logicielle

Je ne sais pas d'où tu sors les pourcentage indiqués...
Avoir une économie de 50% indique que tu es deux fois plus efficace.
En terme de processeur, cela indique que plus de 50% des opérations calculées ne sont pas des opérations métiers. Ce qui n'est simplement pas le cas pour Java ou PHP (sauf si l'application ne fait pas de calcul ou coder avec les pieds)
En terme de RAM, cela peut s'expliquer assez facilement pas l'environnement chargé. Le framework JavaScript standard étant beaucoup plus léger que celui de PHP ou Java. Cependant, la RAM est très rarement le problème sur les applications ciblées par Java/PHP.

En suite, il est important de savoir si les applications ont été codées en même temps et de la même manière. Car, dans nombreuse applications existantes, une simple ré-écriture (mise au propre) du code induit une amélioration des performances non négligeable.

Cordialement,
Patrick Kolodziejczyk.

Non Patrick je n'ai pas dit 50% mais 30% ou 70%.
C'est à dire pas 1/2 mais 1/3 ou 2/3.

Bon je ne vais pas citer mon hébergeur et tu sais déontologiquement pourquoi (mais si tu le souhaites, on se passe ces données par MP).

La méthode de calcul vient des statistiques que me fournit l'administrateur de mon cloud en occupation CPU.
Peut-être que mon appli est codée avec les pieds, c'est moi qui l'ai faite. Mais j'ai aussi fait l'appli node.js, donc pas de raison que je code mieux en JS qu'en Java.
Je viens d'ailleurs d'en réecrire une de JEE vers node.js et je suis largement au dessus de 70% en Prod.
Cela vient peut-être de mon architecture JAVA qui m'impose 3 serveurs sur 3 VM distinctes (donc 3 CPU) :
1 frontal Apache (qui héberge le certificat)
1 serveur wildfly
1 base de donnée Postgresql
Alors que sous node je n'ai que 2 serveurs sur 2 VM.

De plus en migrant sous Node.js toute la partie JSF a été évacuée par l'adoption d'AngularJS (vive le JavaScript)

On ne peux pas vraiment tirer de conclusions avec un échantillon aussi petit.

> On ne peux pas vraiment tirer de conclusions avec un échantillon aussi petit.

Oui 'est d'ailleurs le sens du billet, pousser au questionnement, plutôt que d'affirmer quoi que ce soit.

Du coup, selon toi, comment peut on généraliser ce genre de questionnement pour en tirer des conclusions applicable à la réalité ?

Sinon, étant dév JS, je suis évidemment ravi de cette news et j'aime beaucoup l'approche très humble d'autran.

Finalement, je dois signaler que je me pose beaucoup de questions, beaucoup d'etonnements, en lisant cette affirmation,
> la RAM est très rarement le problème sur les applications ciblées par Java/PHP.

Surtout en ce qui concerne php, vu que java, je ne l'ai jamais pratiqué.

Je comprends pas le coup du php.

Que JS/node.js soit plus léger en ressources cpu/ram que Java/"J2EE" ne me choque pas.
C'est presque enfoncer une porte ouverte :
les frameworks sont plus plus volumineux, les jvm à exécuter sont plus lourdes, etc.
Les serveurs d'application Java sont déjà très lourds dans leur execution (websphere et cie consomment une blinde de ressources).

Maintenant, entre JS/node.js et apache/php, je pense sincèrement que Apache/PHP est plus léger.

Je n'ai pas beaucoup cherché mais :
http://zgadzaj.com/benchmarking-node...nst-apache-php

=> conclusion:
* node.js est plus rapide, ce qui s'explique pour moi par sa spécialisation : il ne porte pas tout le code d'apache, uniquement ce dont il a réellement besoin (si le test était sur le render d'une page web statique, amha, apache serait devant)

* son fonctionnement est plus consommateur en ressources (cpu & en moindre mesure, ram)

Je ne suis pas sûr de comprendre ...

Côté serveur, il me semble évident que JS soit plus léger vu que JS s'éxécute côté client.

Côté client, il me semble évident que PHP soit plus léger vu que PHP s'éxécute côté serveur.

Non ?

Il faut aussi voire le coût en ressource côté client, parce que là tu calcul que du côté serveur mais avec Angular tu déplaces une partie des calculs côté client.

Sinon une autre problématique se pose le coût d'un développement Node.JS plutôt que Server Php/JEE/Asp ... à l'heure où les ressources coûtent plus chère qu'un serveur, les entreprises préfèrent se payer de nouveaux serveur que de payer des gens pour optimiser le code...

Envoyé par Shepard

Je ne suis pas sûr de comprendre ...

Côté serveur, il me semble évident que JS soit plus léger vu que JS s'éxécute côté client.

Côté client, il me semble évident que PHP soit plus léger vu que PHP s'éxécute côté serveur.

Non ?

Depuis quelques années, NodeJs permet de faire du javascript côté serveur

Envoyé par Vadrygar

Depuis quelques années, NodeJs permet de faire du javascript côté serveur

Cependant dans le cas présenté, il semble que la remarque soit pertinente. En particulier, quand on considère le replacement d'une partie JSF par du Node.js

@autran : Oui, de 30 à 70%. Ce qui peut-être simplifié en 50% en moyen ? (même si c'est simpliste ) Dans tout les cas, la logique reste la même. Si tu as un tel écart sur les rendements (consommé/produit). Cela implique un consommation de ressource sur des choses inutiles au final. Les applications Java dont tu parle sont en REST ou servlet avec synchronisation avec session ?

Cordialement,
Patrick Kolodziejczyk.

Remontée d'expérience intéressante.
Pourrais-tu nous préciser un peu plus comment tu as fait tes mesures, STP ?

En réfléchissant, ça peut s'expliquer : les moteurs d'exécution JS bénéficie de toute la course technologique qu'il y a eu pour les navigateurs, ce qui a forcément eu un impact sur l'exécution côté serveur.
Pour JAVA, il n'y a qu'Oracle et Open JDK qui est en train de rattraper son homologue.
Pour PHP ... je tairai mon opinion pour ne pas verser dans le troll (je déteste ce langage).

Après, la qualité du code joue beaucoup sur ce genre de mesures. Si tu peux publier des exemples dans les trois langages, ce serait aussi intéressant à analyser ;-) .

Et puis, si tu as le temps, je te conseille d'essayer ReactJS, qui devrait te donner des mesures assez sympa aussi.

@patrick
Non les applications qui ont migré n'étaient pas en REST
Celles sous REST persistent en JEE car leurs WS sont très utilisés par d'autres applications. Je préfère donc garder ces appli critiques en JEE.

Je pense qu'il y a potentiellement une différence se situant au niveau de la gestion de la session et des objets qui s'y trouvent.
Logiquement, les performances sont très dépendante de l'ensemble de l'application. Il me semble complexe d'avoir un cas de benchmark simple sur ce genre de cas.

Il suffit de regarder l'exemple de Netflix avec cet article très interressant : http://yunong.io/2015/07/13/building...js-at-netflix/

Ca parait logique une dizaine de lignes suffisent pr créer un serveur HTTP, pr la partie front avec Angular cela permet de faire du full stack du coup, mais faut pas se leurrer, les applis node.js n'ont pas encore la mm complexité que celle en java (meme si Netflix semble prouver que ce soit possible mm si ils s'appuient encore sur un back java pr certaines parties) !

Pr moi node est particulièrement efficace pr les applis de messagerie instantané et/ou tout appli avec un nbre de connexion simultanées élevées ... pr le reste on refait la roue, il faut de toute façon réécrire des apis etc. en JS et a la place de maven tu utilises gradle quoi, j'exagere mais c'est un peu ça !

J'ai créé une app Angular il y a pas longtemps et le nbre de dependance (comparés au tout début d'angular) a déjà bien gonflé ! Ce qui laisse entendre qu'on se dirige ds la mm direction que Java qq années plus tot ... sauf que Node est basé sur un noyau en C++ si je dit pas de bêtise mais reste en deça d'une appli native en C mais au dessus de Java en terme de performances pures !

Envoyé par youtpout978

Sinon une autre problématique se pose le coût d'un développement Node.JS plutôt que Server Php/JEE/Asp ... à l'heure où les ressources coûtent plus chère qu'un serveur, les entreprises préfèrent se payer de nouveaux serveur que de payer des gens pour optimiser le code...

Ça n'est pas évident. Car aujourd'hui, en terme de communication il est très intéressant pour un entreprise de s'inscrire dans une démarche de développement durable.

De plus tu ne comptabilise que les développeur alors qu'il faudrait faire une comparaison des couts d’hébergement en production qui sont largement en faveur de Node.js
En effet, ton hébergeur te fais payer le cout d'administration du JBOSS alors qu'il est nul pour node.js

Je suis tout à fait d'accord avec @Bono, la publication des codes permettra tout d'abord de comprendre le contexte expérimental et pourquoi pas de contribuer à l'appréciation de l'hypothèse.

Salut Autran,

Tes statistiques sont fausses car tu n'utilises aucun panel! C'est comme si tu disais qu'un couple de blond à 75% de chance d'avoir un enfant blond donc 75% des enfants nés seront blonds ...
Demandes des statistiques plus détaillés à ton hébergeur pour que tu puisses construire ton panel.
Pour moi le GreenIt ne se résume pas que au facteur CPU+RAM de ton serveur, tu as aussi le facteur BP qui joue et aussi le code exécuté coté client, si tu ne fais que servir du JS statique qui produit des boucles infinies coté client, tu auras très peu d'utilisation CPU+RAM de ton coté mais combien coté client ... Surtout que en général tu as un serveur web pour plusieurs milliers d'utilisateurs !

Bonne fin de soirée

@timidou
Je ne dis pas que parce-que la consommation sur le serveur baisse on est forcement dans le greenIT. Je n'affirme rien, je constate et je m’interroge à la cantonade.
Quant à la BP, je ne possède aucune données la dessus. Mon hébergeur ne m'en envoie pas car cet indicateur ne fait pas partie du tableau de bord. cette donnée n'étant pas discriminante pour nous sur l'axe financier

@SMohamed6
Je ne pense pas que publier 20000 lignes de code source puisse vraiment nous éclairer
En plus je ne suis pas certain que ça tienne sur un billet.

comparer Node.js qui à un moteur récent avec un PHP au moteur vieillissant(bientôt généralisation PHP 7) est une hérésie, il faut comparer ce qui est comparable. De plus vus le nombre de failles récurrentes sur Node.js tes performances se payent niveau sécurité

J'ai du mal à voir comment on peut qualifier d'écologique un programme en langage interprété tournant sur un runtime qui lui-même tourne sur un os (généralement virtualisé en plus).

S'il s'agit d'efficacité pourquoi ne pas utiliser du C++ ? D'ailleurs il parait que ce langage est pas mal utilisé par google, facebook, amazon et autres. De plus, il existe pas mal de frameworks web C++ dont certains sont parait-il efficaces, complets et faciles à utiliser :
[url]http://www.webtoolkit.eu/wt[/url]
[url]http://cppcms.com/wikipp/en/page/main[/url]
[url]http://www.treefrogframework.org/[/url]
[url]http://pocoproject.org/[/url]
[url]http://www.tntnet.org/[/url]