Tech Days 2013 – Eco conception logicielle : comment réduire par deux la consommation d’énergie d’une application ou d’un site web

Les Tech Days (la grande conférence annuel de Microsoft à Paris) dans leur version 2013 ont accueilli, comme les années précédentes, une session sur l'éco-conception. Eric Mittelette, Evangéliste en chef de Microsoft France, est particulièrement féru et compétent sur le sujet, et c'est avec plaisir qu'Olivier Philippot et moi-même avons présenté cette session avec lui.

C’était un grand plaisir de présenter aux Tech Days, devant une salle bien remplie, et avec des gens curieux qui nous ont posé plein de questions à la fin. Important aussi de voir que ces sujets du GreenIT et de l’éco-conception logicielle attirent désormais plus qu’un public confidentiel.

Le message fort de cette session était qu’il est extrêmement facile de réaliser des gains substantiels d’énergie.

Olivier a commencé à le montrer en utilisant un système logiciel de mesure de la consommation sur une page web : Web Energy Archive, projet en cours de développement par le Green Code Lab. L’optimisation des images et des CSS, voire la suppression de certaines ressources non utilisées a permis d’atteindre 45% de baisse de consommation. Au final, sur un site fortement sollicité comme celui d’un journal, ce sont 30 tonnes équivalent CO² qui sont économisés, soit 154 000 kms en voiture…

JP a ensuite pris le relai pour montrer une mesure physique (avec une simple prise Plugwise et un dongle USB pour recueillir la donnée) sur l’application qui sert d’exemple dans son livre sur la performance. Entre la version mal codée et celle correcte du point de vue de l’utilisation des ressources, on passe sur un scénario automatisé simplissime de 11 secondes avec un pic à 20 W à 6 secondes avec un pic à 6 W.

Au final, 83% de gain de consommation, soit 3000 € gagnés sur ce seul scénario replacé dans le cycle de vie global de l’application. Le tout sans formation particulière car il s’agit de respecter simplement 5 règles de base que n’importe qui se prétendant développeur connait :

  • Utiliser StringBuilder pour des concaténations nombreuses de chaînes
  • Ne pas faire des appels de services web ou de requêtes SQL en boucle
  • Sortir le plus rapidement possible des boucles
  • Ne réaliser que les opérations immédiatement utiles (lazy loading)
  • N’utiliser des exceptions que dans les cas effectivement exceptionels

Un autre message important, que nous n’avions pas préparé, mais qui est apparu dans la discussion, est l’effet de seuil important entre l’augmentation de performance par optimisation du code, et l’augmentation de performance par ajout de ressources. La première est “gratuite” et doit être favorisée, car elle aide sur toute la chaîne (nombre de machines, consommation électrique, besoin de climatisation, de locaux, etc.). La seconde est à n’utiliser que lorsque la première a été utilisée.

Comment savoir où on se place sur ce seuil et quand on l’a traversé trop vite ? Très simple : employez de VRAIS développeurs, des gens qui seront fiers de leur code, qui auront réalisé un travail de qualité, et sur lequel vous pouvez compter pour tirer la quintessence des ressources de la machine, avant de penser à rajouter un autre serveur.

Pour vérifier, il suffit de mesurer :

Mais comment reconnait-on le bon chasseur développeur du mauvais ? Difficile à dire, mais quelques exemples parmi tant d’autres :

  • le bon développeur sait qu’il vaut mieux faire deux boucles sur la même liste pour réaliser deux traitements plutôt que de réaliser les deux traitements à chaque itération d’une seule boucle, car cette seconde solution réduit les chances d’optimisation du traitement par le cache du CPU.
  • le bon développeur ne met pas un mécanisme de cache sur un traitement tant qu’il n’a pas la preuve par un profileur que le gain compense effectivement le coût en termes d’utilisation de la mémoire et de complexité de mise à jour.
  • le bon développeur réfléchit LONGTEMPS à son code avant de taper la moindre ligne. Vous traverseriez un pont réalisé par un ouvrier qui n’a pas fait de calcul de résistance des matériaux avant de poser les poutrelles par dessus la rivière ?

Un autre moyen de trouver un bon développeur : regardez s’il est fier en cherchant le signe ci-dessous (il peut y avoir besoin, le cas échéant, de lui demander de retirer sa polaire élimée) Sourire

Technologie: 
Tags: 

Ajouter un commentaire