Merge pull request #13 from UTT-GL03/prototype4

Prototype4

README.md

@@ -175,3 +175,35 @@ En revanche, nous avons maintenant une utilisation continue du CPU par la base d
 Fig.8 : Profil dans le temps de l'impact de la base de données lors de la consultation de la page d'accueil.
 
 De ces différentes mesures, nous pouvons retenir que l'effet de l'introduction d'une base de données, quoique négligeable, est, pour l'instant, plutôt défavorable d'un point de vue écologique. Le bilan de ce changement devrait cependant rapidement s'inverser avec l'augmentation de la quantité de données gérées.
+
+# Prototype n°4 : Fonctionnalités pour le scénario prioritaire avec filtrage des données
+
+### Passage à l'échelle
+
+Dans notre cas, l'augmentation de la quantité de données à traiter proviendra essentiellement du nombre de villes prises en compte ainsi que du nombre de dates. Pour simuler un volume important de données lié à une augmentation du nombre de villes, nous avons conservé les trois villes initialement sélectionnées (Toulouse, Paris, Troyes). Cependant, nous avons ajouté un grand nombre de nouvelles dates. Cela reproduit l'effet de nombreuses villes avec quelques dates, tout en utilisant un nombre restreint de villes avec une multitude de dates. Cette approche nous permettra d'analyser les différences de performance de manière efficace.
+
+### Évolution de l'impact environnemental avant correction
+
+La figure 9 illustre l'impact du passage à l'échelle, de 15 à 9 000 fiches météorologiques (une fiche correspondant à une ville et une date). On observe, sur le backend, une multiplication par 5,8 de l'impact lié au processeur et, surtout, une augmentation significative de l'impact réseau : une multiplication par 11 pour le frontend, ainsi qu'une explosion non quantifiable (de 0 à 20 mWh) pour le backend.
+
+![image](./benchmark/screenshots/GF_analys_EcoMeteo_huge_amout_data_overview.png)
+
+Fig.9 : Évolution de l'impact de la consultation de la page d'accueil en passant de 15 articles à 9000.
+
+### Prise en compte du passage à l'échelle
+
+Dans notre contexte, pour contrer les défis liés à la mise à grande échelle, nous adopterons une stratégie visant à limiter les données récupérées à celles strictement nécessaires au moment de la consultation.  
+
+En effet, récupérer toutes les données dès le début, comme cela pourrait être fait dans une application classique, entraînerait une surcharge inutile du système et un impact environnemental accru. À la place, nous mettrons en place un mécanisme de requêtes ciblées, où les fiches météo seront récupérées en fonction de paramètres spécifiques : **la ville** et **la date**.  
+
+Ainsi, au lieu de charger l'ensemble des données disponibles, nous demanderons uniquement les informations nécessaires pour la fiche météo en cours de consultation. Ce fonctionnement nous permettra :  
+
+1. De réduire le volume de données transférées et traitées, optimisant ainsi les performances du système.  
+2. D'offrir une expérience utilisateur cohérente, sans ralentissement lié à la surcharge des ressources.  
+3. De minimiser l'impact environnemental en adaptant la consommation d'énergie aux besoins réels de l'utilisateur.
+
+Vous pourrez constater les améliorations réalisées grâce à cette optimisation.
+
+![image](./benchmark/screenshots/GF_analys_EcoMeteo_huge_amout_data_optimized_overview.png)
+
+Fig.10 : Évolution de l'impact de la consultation de la page d'accueil en ne récupérant que les fiches météo nécessaires.