- Dans les environnements JavaScript et Node.js, Joi, une bibliothèque de validation, est plus lente que d’autres bibliothèques
- Remplacer Joi par une autre bibliothèque peut laisser espérer un gain de performances dans un environnement backend
- Test pour vérifier si une différence de performances significative peut apparaître dans une application backend
- Les tests sont réalisés avec k6, avec également lodash et class-transformer
- Résultats des tests de performance :
- native vs lodash : aucune différence de performances
- object literal vs class-transformer : aucune différence de performances
- sans validation vs Joi : malgré les performances plus lentes de Joi, aucune différence de performances n’apparaît
- Les performances sont importantes, mais dans un projet déjà en cours, il est possible que le gain ne soit pas perceptible au regard du temps investi pour effectuer le changement
8 commentaires
J’ai l’impression que l’auteur cherche moins à améliorer une situation de goulot d’étranglement qu’à soutenir que, dans un environnement proche des conditions réelles, les écarts de performance entre les bibliothèques de validation ne sont pas vraiment très significatifs.
Que se passerait-il si l’on supposait qu’il ne s’agit pas d’un service ne comportant que des tâches liées aux E/S, comme l’explique l’article, mais d’un service avec des tâches CPU-bound ?
Les services en environnement réel sont plus complexes qu’on ne le pense. Un serveur ne se limite pas à une API servant les données nécessaires pour afficher l’UI.
Comme les opérations de validation et de sérialisation JSON s’exécutent sur le thread principal, ce n’est pas quelque chose à prendre à la légère. Dans l’écosystème backend TS, les outils les plus couramment utilisés sont
class-validator/class-transformer. Et leur débit de validation est d’environ 4 Mo par seconde, ce qui signifie qu’on ne peut pas traiter plus de 4 Mo par seconde sur le thread principal.Les entrées/sorties avec la base de données, elles, s’exécutent sur des threads d’arrière-plan plutôt que sur le thread principal, donc du point de vue d’un serveur backend (serveur TS), cela n’a pas un impact majeur sur le nombre de connexions simultanées. Selon la nature du service, si le volume de DTO transmis en une fois est important, une validation lente peut au contraire être encore plus préoccupante (dans un cas réel, lors de la création d’un service avec une grande quantité de données par requête, il y a même eu un cas où le nombre de connexions simultanées sur NestJS est tombé à un seul chiffre).
Je suis d’accord : pour prétendre parler de « situations réelles », l’exemple de situation réelle avancé par l’auteur est bien trop limité.
Comme l’a dit la personne au-dessus, c’est un benchmark dans lequel il est difficile de comprendre pourquoi des entrées/sorties DB ont été incluses. Et les lenteurs de validation et de sérialisation nuisent davantage aux performances du serveur côté
response DTOqu’au niveau desrequest DTO. Enfin, lorsqu’on mène ce type d’expérience de benchmark, il ne faut pas se limiter à un seul DTO, mais tester avec différents types.En pratique, lorsqu’il n’y a pas d’I/O DB et que l’on teste des DTO aux structures variées, les résultats diffèrent.
J’ai l’impression qu’à la base, c’est plutôt la connexion à la base de données qui constitue le goulot d’étranglement, donc je me demande si le sujet n’est pas mal posé.
On a l’impression que c’est présenté comme s’il y avait un gain de performances alors qu’en réalité il n’y en a pas, mais en fait le goulot d’étranglement est dès le départ du côté de la base de données, donc le fait d’écrire l’article en se concentrant sur l’amélioration d’un point qui n’est pas le goulot risque de prêter à confusion.
Dans la plupart des environnements, améliorer les performances signifie éliminer les goulets d’étranglement. Lorsqu’on optimise la validation, il faut d’abord avoir identifié que c’est elle qui constitue le goulet d’étranglement.