IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Open source et architecture logicielle

[Actualité] JavaScript s'inscrit-il dans une démarche Green IT ?

Note : 4 votes pour une moyenne de 4,25.
par , 05/03/2016 à 17h10 (3861 Affichages)
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 ?

Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Viadeo Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Twitter Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Google Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Facebook Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Digg Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Delicious Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog MySpace Envoyer le billet « JavaScript s'inscrit-il dans une démarche Green IT ? » dans le blog Yahoo

Mis à jour 07/03/2016 à 10h43 par ClaudeLELOUP

Catégories
Javascript , Développement Web

Commentaires

Page 1 sur 2 12 DernièreDernière
  1. Avatar de kolodz
    • |
    • permalink
    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.
  2. Avatar de autran
    • |
    • permalink
    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)
  3. Avatar de Theta
    • |
    • permalink
    On ne peux pas vraiment tirer de conclusions avec un échantillon aussi petit.
  4. Avatar de mh-cbon
    • |
    • permalink
    > 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é.
  5. Avatar de gagaches
    • |
    • permalink
    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)
  6. Avatar de Shepard
    • |
    • permalink
    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 ?
  7. Avatar de youtpout978
    • |
    • permalink
    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...
  8. Avatar de Vadrygar
    • |
    • permalink
    Citation 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
  9. Avatar de kolodz
    • |
    • permalink
    Citation 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.
  10. Avatar de Bono_BX
    • |
    • permalink
    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.
  11. Avatar de autran
    • |
    • permalink
    @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.
  12. Avatar de kolodz
    • |
    • permalink
    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.
  13. Avatar de spyserver
    • |
    • permalink
    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 !
  14. Avatar de autran
    • |
    • permalink
    Citation 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
  15. Avatar de SMohamed6
    • |
    • permalink
    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.
  16. Avatar de timidou
    • |
    • permalink
    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
  17. Avatar de autran
    • |
    • permalink
    @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
    Mis à jour 17/04/2016 à 11h48 par autran
  18. Avatar de autran
    • |
    • permalink
    @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.
  19. Avatar de TiranusKBX
    • |
    • permalink
    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é
  20. Avatar de Invité
    • |
    • permalink
    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]
Page 1 sur 2 12 DernièreDernière