Performance & Benchmarks
Pourquoi créer un nouveau framework alors que NestJS existe ? La réponse tient en deux mots : Performance et Légèreté. (Bon, et surtout parce qu'on était limités par le sujet de Transcendence...)
Nous avons comparé ce framework face au géant du marché : NestJS (configuré avec FastifyAdapter).
🔬 Méthodologie
Les tests ont été réalisés sur une machine puissante pour pousser les frameworks dans leurs retranchements, sans goulot d'étranglement matériel.
- CPU : AMD Ryzen 9 3900X (12 cœurs, 4.5 GHz)
- RAM : 32Go DDR4 3200Mhz
- Stockage : SSD NVMe PCI 4.0
- Outil :
autocannon(100 à 1000 connexions simultanées)
Pour être équitable, NestJS a été configuré avec FastifyAdapter (plus rapide qu'Express) et le logger a été désactivé sur les deux frameworks.
🚀 1. Vitesse Brute (Hello World)
Ce test mesure l'overhead (le coût) du framework. Il s'agit d'une route simple retournant un JSON { hello: 'world' }.
| Framework | Requêtes / Seconde (RPS) | Latence Moyenne |
|---|---|---|
| NestJS | 32,372 | 2.54 ms |
| Ce Framework | 35,594 | 2.10 ms |
Résultat : +10% de performance brute grâce à l'architecture "Bare Metal".
💾 2. Base de Données (SQLite)
Test réaliste impliquant une lecture en base de données. Les deux frameworks utilisent le driver ultra-rapide better-sqlite3.
| Framework | Requêtes / Seconde (RPS) | Latence P99 (Pire cas) |
|---|---|---|
| NestJS | 25,766 | 6 ms |
| Ce Framework | 28,792 | 5 ms |
Résultat : Même avec des I/O, la légèreté du framework permet de traiter ~3 000 requêtes de plus par seconde.
🛡️ 3. Validation de Données (DTO)
C'est ici que l'écart se creuse.
- NestJS utilise
class-validator(basé sur la réflexion, lent au runtime). - Ce Framework utilise la validation native AJV de Fastify (compilé au démarrage, ultra rapide).
Scénario : Envoi d'un POST avec vérification d'email, âge minimum et longueur de chaîne.
| Framework | Requêtes / Seconde (RPS) |
|---|---|
| NestJS | 16,143 |
| Ce Framework | 18,720 |
Résultat : +16% de performance sur les routes avec validation complexe.
🧠 4. Consommation Mémoire (Le K.O. Technique)
La vitesse est importante, mais dans un environnement Microservices (Kubernetes, AWS Lambda), la RAM coûte cher.
C'est ici que notre architecture brille par sa simplicité. Contrairement à NestJS qui instancie un conteneur IoC complexe, nous restons au plus proche du métal / Fondation.
Consommation RAM sous charge (Load Test)
| Framework | RAM Utilisée | Gain |
|---|---|---|
| NestJS | 232 MiB | - |
| Ce Framework | 110 MiB | -52% 📉 |
En utilisant ce framework, vous pouvez faire tourner deux fois plus de microservices sur le même serveur qu'avec une architecture NestJS standard, tout en traitant 15% de trafic en plus. Merci Transcendence 😭