JavaScript s'inscrit-il dans une démarche Green IT ?
Les applications Node.js semblent moins voraces en ressources que celles basées sur JEE ou PHP

Le , par autran, Rédacteur
Je remarque que les applications basées sur Node.js que je déploie sont beaucoup moins voraces en ressources processeurs et RAM que celles basées sur JEE ou sur PHP.

L'économie se situe entre 30 et 70 % sur les dépenses processeurs et RAM.
J'ai quantifié cette économie en mesurant le différentiel moyen entre une architecture JEE et une architecture Node.js pour des applications de même niveau de qualité (performances – nombre d'utilisateurs – volumes d'objets métier – taille des bases de données – contraintes cyber…).

Ces mesures, par leur importance (jusqu'à 70 %) laissent penser que ce levier pourrait avoir un effet majeur sur la réduction de l'empreinte carbone induite par les structures d’hébergement mutualisées (le cloud).

En étudiant les statistiques produites (écart type, coefficient de régression…) il apparait également que les économies de ressources sont centrées autour de 30 % et 70 %. Ces deux quanta sont sans doute induits par la différence d'architectures exigibles en production pour chacune de ces deux technologies dans un hébergement de production.

J’écris cet article en toute humilité, car je ne connais pas les règles de passage de la consommation CPU + RAM à la dissipation thermique et l'impact carbone afférent (je ne suis ni électronicien ni développeur openstack). Mais il me semble, même si la correspondance entre la consommation en ressources et l'empreinte carbone n'était pas bijective (voire linéaire), que sous cet éclairage JavaScript soit intéressant du point de vue de l'informatique verte.

Et vous ?
Avez-vous fait des constatations similaires ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster un commentaire

Avatar de kolodz kolodz - Modérateur https://www.developpez.com
le 06/03/2016 à 9:29
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.
Avatar de autran autran - Rédacteur https://www.developpez.com
le 06/03/2016 à 12:40
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)
Avatar de Theta Theta - Membre confirmé https://www.developpez.com
le 07/03/2016 à 10:07
On ne peux pas vraiment tirer de conclusions avec un échantillon aussi petit.
Avatar de mh-cbon mh-cbon - Membre du Club https://www.developpez.com
le 07/03/2016 à 10:14
> 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é.
Avatar de gagaches gagaches - Membre averti https://www.developpez.com
le 07/03/2016 à 10:50
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)
Avatar de Shepard Shepard - Membre confirmé https://www.developpez.com
le 07/03/2016 à 11:24
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 ?
Avatar de youtpout978 youtpout978 - Membre expert https://www.developpez.com
le 07/03/2016 à 11:42
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...
Avatar de Vadrygar Vadrygar - Membre du Club https://www.developpez.com
le 07/03/2016 à 11:51
Citation Envoyé par Shepard;bt2280
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
Avatar de kolodz kolodz - Modérateur https://www.developpez.com
le 07/03/2016 à 12:03
Citation Envoyé par Vadrygar;bt2283
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.
Avatar de Bono_BX Bono_BX - Membre confirmé https://www.developpez.com
le 07/03/2016 à 13:45
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.
Offres d'emploi IT
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil