L’implémentation du Design Pattern Observer peut-elle répondre à des exigences Green IT ?

Toujours plus vite, toujours moins cher, pour répondre à un marché de plus en plus compétitif, telle est la constante obstination de la majorité de nos sociétés actuelles. Héritières incontestées de la fin des années 90, elles s’évertuent encore aujourd’hui à favoriser le profit court terme à la poursuite vaine d’une croissance sans limite, au dépend d’un modèle plus durable.

Nous en payons déjà les conséquences économiques directes.

Qu’en est-il de l’environnement ? De nombreux chiffres assez évocateurs ont déjà été mis en évidence, quoi que remis en question par certains détracteurs intéressés.

Nous démontrons aujourd’hui l’importance de l’émission carbone globale liée aux TIC et de la nécessité de réagir à travers notamment des bonnes pratiques simples et la mise en place concrète du « Green IT ».

De telles considérations nous amènent à poser la simple question : comment ? Comment serait-il possible, pour ces mêmes entreprises prisonnières « volontaires » d’un modèle économique mondial aussi complexe, de prendre le minimum de temps de bien faire les choses ou encore de travailler sur une R&D dans le domaine du Green IT ?

Même si aujourd’hui, de nombreux acteurs (SSII, Cabinets, etc.) peinent à s’approprier ces réflexions tant il faut livrer le produit soit le plus rapidement possible car « nous sommes au forfait », ou le plus lentement possible car « en régie » (ne parlons pas de l’ACV logicielle qui en résulte) ; voici notre modeste contribution sur l’étude et l’intérêt du pattern Observer en espérant qu’elle puisse éveiller de bonnes réflexions pour ceux qui sont porteurs de changements.

À l’origine des temps, l’optimisation forcée…

« Je n’ai que quelques 8 Mo de RAM, je ne dois pas faire n’importe quoi, je n’ai pas le choix et je suis un développeur qui réfléchit, par nécessité évidente. »

Quand pourtant virent le jour des processeurs toujours plus puissants (suivant la loi de Moore) et du matériel toujours plus impressionnant tant sur le stockage que la mémoire vive. Une frénétique explosion technologique que tout sembla ne pouvoir arrêter sauf les limites physiques de notre système.

Malheureusement suite à l’émergence constante et pourtant intéressante de ces nouvelles possibilités naquit :

Le dirty pattern…

C’est ici que nous prenons la main avec l’exemple concret d’un sujet de programmation qui sera sûrement un jour au programme de nos écoles primaires (en 2030 ?) : Programmer l’affichage web de l’objet temps-réel le plus simple qui soit : La date et heure système.

Vous avez dit simple ?  Ne nous méprenons pas, certains y verrons là l’occasion toute faite de nous sortir le pire des dirty pattern qui soient pour un besoin aussi banal : La boucle infinie en tentant de réaliser un faux long polling.

Ce faux long polling que nous appelerons ici « non maîtrisé » représente une boucle infinie côté serveur où l’on placera dans notre exemple le dit objet « Date ».  Je vous laisse imaginer les ressources « inutiles » nécessaires…

Fort heureusement, il est possible d’optimiser tout cela en codant un vrai long polling et en y ajoutant notamment des fonctions d'attente. Mais n’oublions pas non plus qu’en plus de cette boucle quasi infinie il y aura des interrogations et affichages à réaliser côté client… Cela reste donc à étudier.

« C’est très bien tout cela, mais où sont vos mesures ? »

C’est vrai et tout naturel, après tout c’est bien l’objet de cet article ? L’Observer Pattern ?  Alors allons-y et rentrons dans le vif du sujet.

Voici ci-dessous, l’expérience que nous avons pu réaliser avec toutes les perspectives que cela peut nous apporter dans le domaine.

Les modèles :

Tout simplement, dans tous les cas du côté serveur :

En PHP

<?php

//$today="test";

$today = date('Y-m-d H:i:s');

print_r($today);

?>

Ou encore en JAVA

<% java.text.SimpleDateFormat dateFormatter = new java.text.SimpleDateFormat("dd-MM-yyyy' 'HH:mm:ss");%>
<%= dateFormatter.format(new java.util.Date()) %>

Ce qui diffèrera dans notre étude sera donc la programmation côté client, la seule condition à respecter sera d’utiliser AJAX.

Cas 1 : Sans Pattern (et sans framework)

<HTML>

                <BODY>                                                

                               <SCRIPT type="text/javascript">                         

                               var url = './heure.php';                         

                               function getHeureSysteme(){                                                             

                                               var xhr = null;

                                               var xhr = new XMLHttpRequest();

                                               xhr.open("GET", url, false);

                                               xhr.send(null);                                      

                                                              

                                                var datHeure=xhr.responseText.split(' ');

                                               var valeur1 = datHeure[0];

                                                var valeur2 = datHeure[1];       

                               //Il suffit de mettre à jour les DIV

                                               document.getElementById('date').innerHTML = valeur1;

                                               document.getElementById('heure').innerHTML = valeur2;                                   

                               }                                                             

                               //On lance la fonction 1 fois par seconde

                                               setInterval(getHeureSysteme,1000);

                               </SCRIPT>                             

                               <div id="date"></div>

                               <div id="heure"></div>                        

                </BODY>

</HTML>

Cas 2 : On optimise… Avec Pattern (et avec framework, jquery.js ou prototype.js*)

*A noter que le framework jquery nous a permis de gagner 2 à 3ms en temps de réponse par rapport au prototype.

 

Afin d’éviter une hémorragie de code dans notre article, préférons la modélisation ci-dessous afin de bien illustrer ce qui a été programmé :

Inspirations : AJAX 4ème édition Le guide complet ISBN, Bruno Catteau – Nicolas Faugout – ISBN : 978-2-300-022029 / 2009

Première question : Quels sont les apports du pattern Observer en termes de performance et d’utilisation de la charge processeur ?

Dans notre expérience, nous avons développé d’une part le pattern Observer en Ajax avec pour même objectif d’afficher la date et heure système au niveau de notre navigateur, d’autre part pour un même besoin un affichage sans pattern (utilisant également Ajax).

De ce pattern Observer résulta  une performance accrue en termes de temps de réponse (40ms to 10ms) mais également une diminution significative de la charge processeur nécessaire (voir figure ci-dessous).

Deuxième question : L’implémentation du pattern Observer a-t-elle un impact significatif en termes de consommation énergétique ?

C’est toujours avec nos différentes implémentations que nous avons pu réaliser quelques mesures de consommation énergétique.

Selon les mesures réalisées (voir figure ci-dessous), nous avons pu en déduire que l’implémentation du Design pattern observer en AJAX, a pu réduire de 73% la consommation énergétique. Consommation qui se compte en mW.h et qui par conséquent ne risque pas de révolutionner l’émission de CO2 des TIC de toute une planète, quoi qu’en en multipliant l’économie par le nombre d’utilisateurs substantiels d’outils numérique et notamment le web ainsi que toutes les applications qui en découlent, nous pourrions envisager un résultat très intéressant.

Mais là n’est plus, notre problématique. Le fait d’observer l’objet temps-réel simple qu’est « Date », nous fait penser qu’il y a un peu de « tricherie » dans tout ça.

En effet, nous connaissons cet objet date, si bien que nous savons qu’il est périodique à raison d’une mise à jour par seconde.

Tout naturellement, notre penchant vers l’optimisation nous a fait programmer des appels de classe à raison d’une fois par seconde. Pourquoi en faire plus que de raison ?

Imaginons maintenant que nous ne maitrisions pas notre objet, imaginons qu’il soit le pire des objets temps-réels à savoir qu’il aurait pour propriété un changement d’état aléatoire.

Voici, figures ci-dessous, malgré un « bon » design pattern, les résultats catastrophiques (charge processeur comme consommation énergétique) qu’induisent une mauvaise connaissance de l’objet ou un manque de temps pour penser à optimiser.

En comparant les patterns optimisés sur leur nombre d’appels de la classe « Date » (1 par seconde et 10 par seconde), nous  observons ci-dessus que la charge processeur augmente de cinq fois, de même pour la consommation énergétique ci-dessous qui augmente de 86,4%.

Perspectives et conclusion de notre article :

Un certain nombre de bonnes pratiques ou solutions sont envisageables afin de répondre en partie à nos problématiques Green IT, voici quelques propositions :

  • Implémenter des (Green) Design Patterns au lieu de faire les choses trop vite ou trop mal en laissant place aux dirty patterns ou codes sans structure propre, ni de bonne qualité.
  • Etudier et analyser autant que faire se peut l’objet temps-réel (ou non) que l’on souhaite implémenter afin d’optimiser dès la conception le nombre d’appels de classe prévu (diminuant ou évitant ainsi les surcharges inutiles et consommatrices en énergie)
  • Etudier, et utiliser de nouveaux design patterns et framework permettant d’optimiser (ou conserver) la performance et de gagner en consommation énergétique.

En ce dernier point nous pensons notamment au Reverse-Ajax, mais également à l’utilisation de frameworks tels que Node.js ou encore de solutions comme Ajax Push Engine qui demande l’implémentation du javascript côté client mais également côté serveur.

Ceux-ci restent néanmoins à expérimenter, puis à mesurer, et ferons bien naturellement l’objet d’un second article.

 

Nicolas GUTOWSKI - Membre du Green Code Lab

Groupe ESAIP

 

 

 

Technologie: 
Catégorie: 

Ajouter un commentaire