Quelles ressources réduire dans le cadre de bonnes pratiques d’éco-conception logicielle : Traitements côté serveurs ou côté utilisateurs ?

Reading Time: 3 minutes

Une des premières réponses à la question “quelles ressources” est : toutes ! Mais il est nécessaire d’avoir une réponse plus précise car certaines pratiques vont privilégier une économie côté serveurs, d’autres côté mémoire plutôt que CPU. Il y a des optimisations gagnantes pour tous les domaines mais malheureusement, le comportement des systèmes informatiques est plus capricieux !  

La piste directrice est la prolongation de la durée de vie du matériel, que ce soit pour le terminal ou pour les serveurs. On verra que pour des gains environnementaux, la diminution de l’énergie sera elle aussi une piste. 

Dans un précédent article, nous traitions de la nécessité d’optimiser l’énergie dans le cas des appareils mobiles. Aujourd’hui nous tentons de répondre à la question : quelle architecture mettre en place, et en particulier mettre les traitements côté utilisateurs ou côté serveurs ? 

La réponse est : traitement côté serveur à privilégier…

La réponse est plutôt simple : chargeons les serveurs ! En effet, lorsqu’on prend les ACV et les analyses d’impact, on observe un impact beaucoup plus fort côté utilisateurs (Exemple avec notre étude sur l’impact de la lecture d’une vidéo). Les serveurs sont mutualisés et sont optimisés pour absorber une charge. Le gestionnaire pourra de plus gérer des fluctuations de charge avec du Power Capping (absorption de pic de charge en maintenant une consommation d’énergie maîtrisée). La durée de vie des serveurs pourra elle aussi être gérée (du matériel pouvant aller jusqu’à 10 ans de durée de vie). Le respect d’une politique Green IT pourra aussi être mieux suivi et partagé.

Les terminaux quant à eux, malgré des processeurs puissants, n’ont pas ces avantages. Très peu de maîtrise de la durée de vie, pas de gestion de la santé du système, une fragmentation des puissances et donc des comportements…

…mais attention aux ressources et à la scalabilité

S’il est préférable de placer les calculs côté serveurs, cela n’est pas une excuse pour ne pas optimiser l’impact côté serveurs. La scalabilité et la montée en charge est possible mais à surveiller. Car rajouter une instance virtuelle aura un impact sur le futur besoin d’ajout de machine physique et donc viendra alourdir l’impact environnemental.

De plus, limiter la consommation d’énergie sera nécessaire car une forte demande en énergie se transférera en une augmentation de la puissance consommée sur la baie de serveurs et des besoins de refroidissement plus forts.

Et le coût des allers retours des allers-retours réseau dans ce cas ?

La question se pose sur les échanges réseaux si l’on déplace des calculs côté serveurs. Il s’agit actuellement d’un faux problème car les échanges sont trop nombreux. La ressource réseau et serveurs étant vue comme “gratuite” et les architectures allant de plus en plus vers du service / micro service, les traitements côté utilisateurs appellent trop les datacenters. Il faudra plutôt maîtriser le nombre d’échanges réseau, quel que soit le choix d’architecture.

Est-ce le cas actuellement dans les pratiques d’architecture ?

Cela n’a pas été la tendance de ces dernières années. En effet, l’arrivée de plateformes utilisateurs puissantes, i.e. avec des processeurs multicœurs et des connexions réseaux performantes, ont poussé à déplacer beaucoup de traitements côté utilisateur. Les Frameworks de développement, en particulier les Frameworks JavaScript, ont permis cela.

Cependant, la tendance commence à s’inverser. On peut notamment citer le Server-Side Rendering (SSR) avec par exemple next.js ou la génération de blogs statiques avec Hugo. On peut aussi voir les techniques maximisant l’usage des éléments déjà présents sur le terminal de l’utilisateur comme le moteur du navigateur web en utilisant plutôt du CSS que du JS.

Nous tenterons de répondre dans les prochains articles : quelles ressources (CPU, mémoire…) doit-on optimiser en priorité ?