| marp |
|---|
true |
- eco - conception de services numériques
- Créer une architecture applicative modulaire
- Choisir un format de données adapté
- Éliminer les fonctionnalités non essentielles
- Réduire le volume de données stockées au strict nécessaire / Mettre en place une politique d'expiration et suppression des données
- Faire preuve de frugalité dans la présentation et dans le déplacement des données
- Nombreuses bonnes pratiques pour le développement front
- Limiter l'obsolescence des terminaux utilisateurs
- Limiter la consommation des terminaux utilisateurs !
- Particularité des serveurs et du réseau :
- équipements rentabilisés
- il faut en maîtriser la consommation
- Attention aux impacts des développements sur les serveurs pour le client :
- pagination
- protocoles
- caches côté client
- Installer le minimum requis sur le serveur
- Mettre en place une architecture élastique
- Réduire au nécessaire les logs des serveurs
- Utiliser la version la plus récente du langage
- de petits incréments ?
- Principe des caches
- ne pas redépenser du temps/de la ressource pour une donnée qui a déjà été obtenue
- Durée de vie
- Partage des caches
- l'utilisation du cache http côté client s'envisage à chaque requête pour stoquer la réponse obtenue suivant les instructions dans les en-têtes.
- lors de la réutilisation d'une ressource (url identique), le navigateur vérifie si elle est en cache et utilisable directement
- l'en-tête **
Cache-Controlreçue lors de la première réponse déclenche l'utilisation du cache côté clientCache-Control: no-store: aucune mise en cache. à chaque nouvelle "requête" :- => ☹ recalcul côté serveur 🔥
- => ☹ renvoi des données sur le réseau 🔥
Cache-Control: max-age=31536000(s) : mise en cache pendant un an. à chaque nouvelle "requête" :- => 🙂 aucun recalcul côté serveur 🍃
- => 🙂 aucun envoi des données sur le réseau 🍃
Cache-Control: no-cache: mise en cache, revalidation systématique. à chaque nouvelle requête :- => ☹ recalcul côté serveur 🔥
- => 🙂 aucun envoi des données sur le réseau 🍃 (si pas de changement)
- l'en tête
ETagcontient un hash de la ressource calculé côté serveur et utilisé lors de la revalidation d'une ressource mise en cache :- envoi d'une requête
GETpar le navigateur avec en-têteIf-None-Match: ${etag.value}- réponse
304 Not modifiedsans body si le hash recalculé par le serveur est identique - réponse
200 OKavec la ressource dans le body sinon
- réponse
- envoi d'une requête
- enfin
Cache-Control: must-revalidate, max-age=600:must-revalidateindique au serveur qu'il doit revalider la ressource lorsqu'elle périme après 10 min
Première requête à 10h
Deuxième requête à 10h30
Troisième requête à 11h01
Quatrième requête à 12h31
- Avec Spring MVC
- API pour l'en-tête
Cache-Control - Filtre pour écrire les en-têtes
etaget intercepterIf-None-Match - NB : pour les usages standards, il est préférable de laisser le filtre ShallowEtagHeaderFilter gérer entièrement les en-têtes
eTagplutôt que de faire cela manuellement dans le contrôleur
- API pour l'en-tête
- Au niveau du serveur applicatif :
- limiter la sollicitation des autres ressources (réseau) 🍃🍃🍃
- préserver les ressources de calcul 🍃
- Répondre plus rapidement aux requêtes utilisateur 🙂
- Infinispan à l'Insee
- Principe simple :
- pour une méthode idempotente
- à chaque premier appel à la méthode avec des arguments donnés, on met en cache la réponse calculée
- aux appels suivants avec les mêmes arguments, on ressert la même valeur sans refaire le calcul
- Expiration et éviction
- Cache partagé (distribué ou répliqué) entre plusieurs instances de l'application
- Intégration de Infinispan avec Spring boot (ne pas oublier
@EnableCachingpour utiliser l'abstraction Spring du cache) - Le cache applicatif permet au sein de l'application de cacher des réponses qui nécessitent beaucoup de calcul ou des données récupérées fréquemment de la BDD
- Pour cacher les réponses d'un WS tiers, on privilégiera l'utilisation d'un cache de client http
- Pour mettre en cache les réponses d'un WS tiers utilisant des en-têtes
cache-controletetagil vaut mieux utiliser un client http qui le gère nativement comme OkHttp - A combiner avec un client REST de plus haut niveau comme Spring Cloud OpenFeign qui se combine bien avec OkHttp
- Demo :
- Vérification de l'utilisation correcte des en-têtes
cache-control,eTag... par la partie contrôleur de l'application à l'aide de MockMvc :DemoControlerTest - Vérification de la bonne mise en cache du client des requêtes reçues depuis un serveur tiers en "mockant" un serveur web :
FridgeClientTest
- Privilégier HTTP/2 à HTTP/1
- Utiliser un serveur asynchrone...
- Compression des documents
- Compression des livrables (jlink / jdeps)
- Bonnes pratiques pour les données / SQL :
- Éviter le transfert d'une grande quantité de données pour réaliser un traitement
- Éviter d'effectuer des requêtes SQL à l’intérieur d’une boucle / Optimiser les requêtes aux bases de données
- Favoriser le "Request collapsing"
- Optimisation du code :
- Éliminer les fonctionnalités non utilisées
- Valider votre code avec un Linter
- Plugin Sonar eco-code !
- Optimisation du build :
- mise en cache des dépendances
- image de build optimisées
- mails au format texte
- Cache applicatif
- Http caching spring MVC
- Intégration du cache applicatif Infinispan : Infinispan
- Cache http
- RFC 7234 sur le cache en http
- OpenFeign, OkHttp, tests : cf. liens dans les autres diapos
- Définitions autour du green-it
- Sensibilisation au numérique responsable de l'INR
- 115 bonnes pratiques de codage Green IT