- In JavaScript- und Node.js-Umgebungen ist die Validierungsbibliothek Joi bei der Performance langsamer als andere Bibliotheken
- Wenn Joi durch eine andere Bibliothek ersetzt wird, ist in Backend-Umgebungen eine Performance-Steigerung zu erwarten
- Es wurde getestet, ob sich in Backend-Anwendungen ein signifikanter Performance-Unterschied zeigt
- Die Tests wurden mit k6 durchgeführt, außerdem wurden lodash und class-transformer mitgetestet
- Ergebnisse der Performance-Tests:
- native vs lodash: kein Performance-Unterschied
- object literal vs class-transformer: kein Performance-Unterschied
- non-validation vs Joi: Trotz der langsameren Performance von Joi zeigte sich kein Performance-Unterschied
- Performance ist wichtig, aber bei Änderungen in bereits laufenden Projekten ist der Unterschied im Verhältnis zur investierten Zeit möglicherweise nicht spürbar
8 Kommentare
Ich denke, der Autor will wohl eher behaupten, dass es nicht darum geht, einen Engpass zu verbessern, sondern dass in einer realitätsnahen Umgebung die Leistungsunterschiede zwischen Validierungsbibliotheken nicht besonders signifikant sind.
Was wäre, wenn man annimmt, dass es sich nicht um einen Service handelt, der nur aus den im Artikel beschriebenen I/O-bound-Tasks besteht, sondern um einen Service mit CPU-bound-Tasks?
Services in realen Umgebungen sind komplexer, als man denkt. Ein Server ist nicht nur eine Data-Serving-API für die Daten, die zum Rendern der UI benötigt werden.
Da Validierung und JSON-Serialisierung auf dem Main-Thread ausgeführt werden, sollte man das nicht einfach auf die leichte Schulter nehmen. Im TS-Backend-Umfeld werden am häufigsten
class-validator/class-transformerverwendet. Und diese schaffen etwa 4 MB validierbaren Durchsatz pro Sekunde, was bedeutet, dass auf dem Main-Thread nicht mehr als 4 MB pro Sekunde verarbeitet werden können.DB-Ein- und -Ausgaben laufen nicht auf dem Main-, sondern auf Hintergrund-Threads, daher hat das – aus Sicht eines Backend-Servers (genauer: eines TS-Servers) – keinen großen Einfluss auf die Zahl gleichzeitiger Verbindungen. Wenn je nach Art des Dienstes jedoch auf einmal große DTO-Mengen übertragen werden, ist langsame Validierung eher noch beängstigender (tatsächlich gab es bei einem Dienst mit großen Datenmengen pro Request einen Fall, in dem NestJS nur eine einstellige Zahl gleichzeitiger Verbindungen schaffte).
Ich stimme zu. Die als Beispiel angeführte „reale Situation“ ist viel zu einseitig, um die Prämisse des Autors „in der Praxis“ zu stützen.
Wie bereits oben erwähnt, ist es schwer nachzuvollziehen, warum DB-I/O in diesen Benchmark aufgenommen wurde. Außerdem richten langsame Validierung und Serialisierung bei der Server-Performance größeren Schaden im Response-DTO als im Request-DTO an. Und schließlich sollte man bei solchen Benchmark-Experimenten nicht nur ein einziges DTO verwenden, sondern mit verschiedenen Typen experimentieren.
Wenn tatsächlich kein DB-I/O vorhanden ist und DTOs mit unterschiedlichen Strukturen getestet wurden, fallen die Ergebnisse in der Praxis unterschiedlich aus.
Von Anfang an scheint eher die DB-Verbindung der Flaschenhals zu sein, daher frage ich mich, ob das Thema nicht falsch gewählt ist.
Es wirkt ein wenig so, als wäre es so dargestellt worden, als gäbe es einen Performancegewinn, obwohl das eigentlich nicht der Fall ist. Tatsächlich ist von Anfang an die Datenbank der Engpass, daher könnte ein Text, der sich auf die Verbesserung eines Bereichs konzentriert, der gar kein Engpass ist, leicht zu Missverständnissen führen.
In den meisten Umgebungen bedeutet eine Leistungsverbesserung, Engpässe zu beseitigen. Bei der Optimierung der Validierung sollte daher zuerst festgestellt worden sein, dass die Validierung tatsächlich der Engpass ist.