Performances Symfony 5 sous Docker Desktop avec WSL2

Aujourd’hui, petit retour d’expérience sur la fonctionnalité WSL2 de Docker Desktop.

Docker Desktop depuis sa version 2.3.0.2 prend en charge WSL2 comme backend. Le but étant de remplacer le backend Hyper-V de base.
Microsoft ayant bien intégré Linux via WSL2, on peut désormais disposer d’un Linux sous Windows avec un partage du système de fichier et un partage réseau et tout ça en utilisant qu’une toute petite machine virtuelle minimaliste. De plus il n’est plus nécessaire d’avoir un Windows avec une license PRO qui était un prérequis à l’installation du composant Hyper-V.

Très intéressant sur le papier, faisons quelques tests ! 😋

Activation du nouveau backend

Plutôt simple, il suffit de cocher une case ! ☑️

On applique et tout roule comme sur des roulettes…

…Enfin presque ! Ça aura pour conséquence de repartir sur une base vierge de Docker. Autrement dit, il va falloir repuller un peu toutes vos images, recréer vos conteneurs etc…
Rassurez-vous, si vous repassez sur le backend Hyper-V, toutes vos données sont conservées.

Inspectons !

Lançons juste un serveur nginx avec un montage de volume.

PS > docker-compose up -d

version: '3'
services:
  http:
    image: nginx
    container_name: nginx
    ports: 
      - "80:80"
    volume:
      - "./:/usr/share/nginx/html"

Observons le montage de volume !

PS > docker inspect nginx

Avec WSL2 le point de montage se situe sur ce dossier :
/run/desktop/mnt/host/c/Users/dorian/workspace/tes_paupieres_sont_lourdes

Alors qu’avec le backend Hyper-V, nous avions : /host_mnt/c/Users/dorian/workspace/tes_paupieres_sont_lourdes

On peut observer un changement du point de montage du dossier.
Dans un cas, nous avions le dossier qui était monté dans la VM faite par Docker, dans l’autre sur le point de montage passant par la VM faite par Microsoft.
Si on passe par la VM faite par Microsoft, on devrait bénéficier de meilleures performances d’E/S d’après ce qu’ils décrivent dans leur article.

Symfonisons !

Pour information, chacun des tests suivants ont été exécutés sur un même disque SSD NVMe.

Test #1: Composer install

Lançons un composer install sur un projet Symfony 5 vierge. PS > powershell -Command "Measure-Command {docker-compose run --rm composer install | Out-Default}"

version: '3'
services:
  composer:
    image: composer
    volumes: 
      - "./:/app"
      - "composer_home:/tmp"
volumes:
  composer_home:

On exécute la commande une première fois pour télécharger les dépendances dans le dossier de cache de composer afin d’éviter les éventuelles variations de bande passante.
Puis on supprime les dossiers pour recommencer :
rm -rf vendor
rm -rf var/cache

Et Voici le résultat pour WSL2 : 3m52s
Et avec Hyper-V : 2m3s

😮 Oui oui, vous avez-bien lu, la VM de Docker est plus performante que celle de Microsoft… Soit une augmentation de 88% du temps.

Activons Docker Desktop pour mon Ubuntu tournant sous WSL2 !

Réessayons d’exécuter cette commande dans le bash de mon Ubuntu cette fois-ci : $ time docker-compose run --rm composer install

Cette fois-ci, le point de montage du volume n’est pas au même endroit. /run/desktop/mnt/host/wsl/docker-desktop-bind-mounts/Ubuntu/zae684grt65432dsq98eza69584a

Résultat : 3m48
On retrouve similairement la même chose qu’avec PowerShell.

Tentons une dernière expérience 😀 !
Utilisation de docker exclusivement dans Ubuntu. Cette fois-ci, il n’y a pas de montage d’un volume monté dans la VM. $ time docker-compose run --rm composer install

Résultat : 5s

Cette fois-ci nous obtenons un résultat plus que satisfaisant 🎉 ! Mais les sources sont côté Linux.
Pour pouvoir y accéder, un partage réseau est directement activé via : \\wsl$\Ubuntu\home\dorian\workspace
Mais dans ce cas c’est l’IDE ou ce que vous faites côté Windows qui risque d’être ralenti… 🐌

Récapitulons, pour un composer install :

Test #2: Affichage de la page d’accueil

Lançons simplement le site dans un conteneur php:7.4-apache.
On supprime le cache de symfony rm -rf var/cache
On accède à http://localhost une première fois pour analyser le temps d’initialisation du cache et une seconde une fois que le cache est initialisé.
Sur les comparatifs suivants, la couleur orange représente le temps d’initialisation de Symfony.

Cache non initialisé

• Volume monté
  • WSL2
  • Hyper-V
• Volume non monté
  • WSL2

Cache initialisé

• Volume monté
  • WSL2
  • Hyper-V
• Volume non monté
  • WSL2

On constate de très mauvaises performances dans le cas où on monte un volume et qu’on utilise WSL2.
Le backend Hyper-v reste compétitif même si il prend tout de même pas loin de deux fois plus de temps à charger que WSL2 contenant les sources directement dans la VM.

Alors, doit-on l’activer ?

Ce qui est bien !

• Les performances sont bien supérieures lorsqu’on ne monte pas un dossier de Windows vers la VM de WSL2.
  On pourrait envisager de déplacer entièrement son dossier workspace dans notre WSL, ce qui pourrait augmenter massivement les performances.
• Nous “récupérons” le système de permissions sur les fichiers de Linux. Cela permettrait d’écarter rapidement des problèmes qui pourraient survenir qu’à la livraison.
• Nous avons toujours le binding des ports sur la machine hôte. On peut toujours accéder à nos applications via localhost même si les services tournent dans la VM de WSL2.

Ce qui est moins bien

• L’indexation des IDE va galérer… Mais ce n’est pas quelque chose qui va s’exécuter toutes les secondes non plus!
• La consommation de RAM est plutôt augmentée. Le backend Hyper-V limitait de base la consommation de RAM à 2Go. Cette fois-ci il va falloir surveiller plus en détail car il peut consommer jusqu’à 80% de votre RAM.
  Il existe un workaround pour limiter la consommation de RAM de la VM

Je pense donc que le temps sacrifié à attendre que son IDE indexe sont projet sera inférieur au temps passé à attendre que les pages se chargent ou qu’un composer install se termine. Malgré tout, l’utilisation d’autres outils graphique (comme Gitkraken) pour gérer les repos GIT sont nettement impactés. Comme indiqué dans l’article de Simon Ferquel, il sera bientôt possible d’exécuter des programmes avec une interface graphique directement dans WSL2 ce qui permettra de profiter de toutes les performances du Linux ! Mais attendez… Pourquoi ne pas installer Linux directement si c’est si bien ..? Ceci est un autre débat !

Dans tous les cas, à mon avis, OUI ! Il faut l’essayer. Pas d’inquiétude, si ça ne fonctionne plus, il vous suffira de décocher la case et vous repasserez sur le backend Hyper-V en un clin d’œil 😉.