Audits
Dans cette partie nous allons comparer l'application initiale (au début de reprise du projet) et l'application améliorée
Plusieurs outils ont été utilisés pour tester la qualité du code. Nous allons présenter des analyses de code réalisées sur Codacy et CodeClimate. Nous avons aussi mis en place des tests unitaires et fonctionnels pour vérifier la qualité du code mais aussi détecter les bugs et dépréciations.
Les analyses Codacy et CodeClimate n'ont pas révélés de problèmes majeurs sur le code de l'application. Néanmoins, des erreurs de sécurités ont été relevés sur la version initiale de l'application. Parmis les plus problématiques, nous retrouvons l'utilisation de variable superglobale sans filtre php particulier ($_SERVER) ainsi que l'affichage de code HTML via la méthode php echo, ce qui est déconseillé.
L'analyse des deux projets (initial et amélioré) sont disponibles en suivant les liens suivants : projet initial / projet amélioré
Concernant PHPUnit, 61 tests ont été réalisés pour un rapport de couverture de l'application supérieur à 85%. Le rapport de tests est disponible ici.
L'audit de qualité de code des deux projets (initial et amélioré) nous as permis d'observer que la montée de version a eu des bénéfices en terme de qualité de code mais aussi de sécurité. Ce n'est pas pour autant que le projet initial n'était pas sécurisé, mais la version de Symfony 3.1 n'était plus supportée et des failles de sécurité commencaient à apparaitre, comme nous l'a rappelé GitHub lors de l'installation du projet :
Dans le même temps, qui dit montée de version Symfony, dit aussi montée de version PHP. Nous sommes passé de la version 5.4 à la version 7.2, ce qui nous as permis d'éliminer bon nombre de méthodes PHP dépréciées.
Nous allons présenter dans cette partie un comparatif de performance entre l'application initiale et l'application améliorée.
Pour les deux outils utilisés (BlackFire, Chrome Dev Tools), nous faisons 1 test de performance par application sur les pages centrales de l'application (login / accueil / liste utilisateurs / liste de tâches).
Après chaque test de performance, chaque application est rechargée entièrement, y compris le cache de l'application (via un php bin/console cache:clear).
Pour compléter nos données, nous avons aussi effectué un test sur chaque application avec l'outil d'Audits de Chrome dev tools. Grâce à ces données, nous allons pouvoir allez plus loin dans notre audit afin d'optimiser notre application. Cet outil nous permet de réaliser un test encore plus fiable sur chaque application car il simule la même connexion entre les tests.
Nous testons les applications en local, elles ne sont pas hébergées en ligne. Nous avons donc adaptés les paramètres au niveau de la console Google pour simuler une connexion identique entre les tests :
- Throttling : Connexion 4G normale
Dans cet audit de performance, nous allons utilisé BlackFire pour relever le temps de chargement et le pic d'utilisation de la mémoire vive nécessaire pour charger la page demandée.
Malheureusement, nous ne pouvons pas avoir accès à d'autres métriques avec un plan gratuit. Nous allons donc compléter cet audit avec les informations du profiler Symfony. Plus précisément, nous allons relever le nombre d'appels à la base de données ainsi que le temps d'éxécution des requêtes SQL.
Résultats des relevés de performance :
| Application initiale | Chargement ressources (s) | Mémoire consommée (mb) | Nombre requêtes SQL | Temps exécution SQL (s) |
|---|---|---|---|---|
| Accueil (déconnecté) | 0.494 | 11.9 | 0 | 0 |
| Accueil (connecté) | 0.822 | 14.8 | 1 | 0.059 |
| Liste des tâches | 0.889 | 14.9 | 2 | 0.103 |
| Liste des utilisateurs | 0.939 | 14.8 | 2 | 0.104 |
| Application améliorée | Chargement ressources (s) | Mémoire consommée (mb) | Nombre requêtes SQL | Temps exécution SQL (s) |
|---|---|---|---|---|
| Accueil (déconnecté) | 0.608 | 17.5 | 0 | 0 |
| Accueil (connecté) | 0.953 | 20.2 | 3 | 0.155 |
| Liste des tâches | 1.24 | 21.9 | 3 | 0.186 |
| Liste des utilisateurs | 1.07 | 21.8 | 2 | 0.197 |
Résultats des relevés de performance
| Application initiale | Accueil (connecté) | Liste des tâches | Liste des utilisateurs |
|---|---|---|---|
| Nombre de requête | 9 | 10 | 7 |
| Ressources externes (mb) | 0.335 | 0.305 | 0.218 |
| Poids des ressources (mb) | 0.334 | 0.303 | 0.216 |
| Chargement total (s) | 5.04 | 4.89 | 4.23 |
| Chargement du DOM (s) | 3.14 | 2.97 | 3.36 |
| Chargement de la page (s) | 3.57 | 3.32 | 3.79 |
| Application améliorée | Accueil (connecté) | Liste des tâches | Liste des utilisateurs |
|---|---|---|---|
| Nombre de requête | 16 | 16 | 14 |
| Ressources externes (mb) | 0.780 | 0.481 | 0.401 |
| Poids des ressources (mb) | 0.9 | 0.7 | 0.6 |
| Chargement total (s) | 3.75 | 3.86 | 3.86 |
| Chargement du DOM (s) | 2.4 | 2.95 | 2.96 |
| Chargement de la page (s) | 2.54 | 3.17 | 3.14 |
Les deux audits réalisés entre l'application initiale et l'application améliorée nous montrent que notre application est légèrement moins performante dans la globalité.
Tous les paramètres testés sont plus importants sur notre application par rapport à l'initiale. Cela s'explique par le fait que nous avons ajouté de nouvelles fonctionnalités à cette application. Le rattachement d'une tâche à un utilisateur et l'ajout d'une gestion des rôles utilisateurs rajoute des requêtes supplémentaires vers la base de donnée. Ces comportements augmentent la consommation de ressources qui est mis en évidence par BlackFire.
D'une manière générale, les deux applications reste très légères avec une consommation de ressource négligeable et peu de requêtes vers la base de données.
Néanmoins, et nous l'avons vu avec l'ajout de nouvelles fonctionnalités, l'application peut vite se ralentir et il faut donc faire attention à la façon d'implémenter les nouvelles fonctionnalités. L'enjeu est de coder de façon la plus ergonomique possible et toujours bien respecter les standards de notre version de Symfony.
Nos résultats obtenus en utilisant la console Google nous permettent de montrer que l'accès aux pages de l'application est plus rapide après avoir fait nos améliorations. Néanmoins, on peut voir que le poids des ressources totales des pages est globalement supérieur sur l'application améliorée.
Alors comment est-ce possible que l'application se charge plus rapidement alors qu'elle gère plus de ressource ?
Cela est du au fait que nous avons installé le service webpack encore géré par Symfony pour nous permettre une meilleure gestion des assets et scripts du site.
De plus, le poids des ressources est plus important sur l'application améliorée car notre application doit maintenant charger un fichier javascript "bundlé" et minifié qui gère beaucoup mieux les images, les scripts etc... Ce système permet aussi une mise en cache supplémentaire (couplé à celle de Symfony) pour accéder aux pages encore plus rapidement.
Pour compléter notre analyse, nous avons utilisé l'outil "Audits" de Chrome Dev Tools pour pouvoir accès à davantage de métrique, notamment sur la performance de l'application.
Les résultats des audits sont disponibles via les liens suivants :
Cet audit a seulement été réalisé sur les pages d'accueil de chaque application.
Ce qu'on peut clairement voir, c'est que l'indicateur de performance est beaucoup moins élevé sur l'application initiale.
En effet, avec l'utilisation de Webpack Encore via Symfony, la gestion des assets est amélioré (minification, cache etc...), cela contribue à l'amélioration de la performance.