Skip to content

TP09

Jump to bottom
ZosiscoIV edited this page May 17, 2025 · 4 revisions

TP9 : High Throughput on Woodytoys

Noms des auteurs : BONTEMS Antoine, SCHOONYANS Ann-Lore, LAMAND Cyril

Date de réalisation : 16/05/2025

1. Un nouveau service Web pour WoodyToys avec Docker Stack

Découverte du service Web

  • Expliquez sur votre Wiki pourquoi l'utilisation de la directive build ne convient pas dans le contexte Docker Swarm.

    • Car les fichiers sources des images ne sont pas transférables d'un noeud à l'autre pour lancer les services sur les autres noeuds, raison pour laquelle il faut passer par Docker Hub pour les récupérer.

  • Documentez sur votre Wiki les flux de données présents, en vous basant sur un schéma commenté.

    • L'utilisateur envoie des requêtes HTTP via son navigateur. Toutes les requêtes sont d’abord reçues par Nginx, qui joue le rôle de reverse proxy. Si la requête concerne une ressource statique (HTML, image, CSS), Nginx répond immédiatement, ce qui réduit la charge du backend.

    • Par contre, si la requête concerne des ressources dynamiques, alors Nginx la transmet au serveur Flask. Flask joue le rôle du backend et interagit avec la base de données MySQL si besoin.

    • Une fois les données récupérées ou traitées, Flask répond à Nginx. Ce dernier renvoie ensuite la réponse finale à l’utilisateur.

Stack Woodytoys

Déploiement sur Swarm

  • Documentez l'adaptation du service afin de le faire tourner sur Swarm.

    • Pour faire tourner les services avec swarm, il fallait changer les build en image et pusher les images sur Docker Hub pour un déploiement plus simple par la suite via d'autre manager par exemple.

  • Documentez vos observation et analyses des limitations, en détaillant les performances chiffrées observées.

    • C'est supra loooooong à charger à cause de l'image en grande partie image

    • La requête lourde dure 5s image

    • Résultat de la commande wget avec 3 replicas vs avec 5 replicas image image

  • Documentez votre campagne de mesure

    • Les mesures ont été prise avec la commande time wget -r http://web.l2-7.ephec-ti.be/, avant et après les changements au niveau du nombre de replicas. Dans l'idéal, il faudrait en faire plusieurs et en faire des moyennes mais j'ai pas le time, sorry not sorry.

Questions

  1. Est-ce que l'augmentation du nombre de replicas résout les problèmes ? Répondez en comparant les premiers chiffres de performance observés avec des mesures effectuées après la modification. Pour chacune des trois limitations, commentez les éventuelles améliorations en étant critiques (les limitations artificielles ne sont peut-être pas représentatives de la réalité).

Augmenter les réplicas ne change pratiquement rien (de ~16.2s à ~16.1s).

  1. Est-ce qu'il y des choses que vous pouvez mettre en place au niveau de Docker Swarm (outre les réplicas) pour améliorer les performances ? (Hints: healthchecks(pour l'api) et placement constraint (pour la database))
  • Un healthcheck au niveau de l'api en vérifiant à intervalle régulier que le service fonctionne correctement
  • Une contrainte de placement pour forcer la DB à être sur un noeud avec les ressources nécessaire pour que celle-ci soit stable

2. Mise en place d'une cache

Avant tout changement au niveau de la cache :

image

Après un changement visiblement pire (alors que rien n'a changé comme l'image avait été gardée identique parce que Docker a pas envie de refaire les builds ou les pulls et que j'avais zappé ce détail) :

image

Après le bon changement :

image

  • Documentez la mise en place du service Redis
    • Le fichier main.py à été adapté pour que les requêtes déjà faites précédemment fasse appel à la cache plutôt qu'à la fonction qui est dans le cadre du TP volontairement ralentie.
  • Documentez les mesures de performances obtenues après cette modification.
    • Lorsqu'une requête pour une ressource déjà demandée à lieu, le temps de réponse est drastiquement augmenté.
  • Analysez ces mesures : Est-ce que cette cache améliore les performances ? de combien ?
    • Oui, pour les requêtes récurrentes, et de beaucoup, de 15sec à quelques ms.

3. CDN

4. Database

Citer et expliquer sur votre Wiki une solution pour améliorer les performances au niveau d'une DB? (une brève description et la présentation de l'un ou l'autre avantage, inconvenient, particularité, ... sont suffisants)

  • On voit ici que la base de donnée est répliquée, la copie est mise à jour régulièrement mais cela permet de répartir la charge entre lecture et écriture pour éviter le problème au niveau de la DB qui est limitée à une seule connexion.

Clone this wiki locally