web-dev-qa-db-fra.com

performance nestjs vs plain express

Je viens de tester les performances sur un simple contrôleur de nid, qui renvoie du texte sur une requête get (pas de base de données). Et le même contrôleur GET simple (middleware) avec express.

J'ai utilisé l'outil WRK pour tester les performances.

Et en conséquence, plain express est 2 fois plus rapide que nestjs. Pourquoi tant de frais généraux sont-ils créés par nestjs?

nestjs
18
Shadowfax

MISE À JOUR - 22.09.2018

Le répertoire des benchmarks a été ajouté au référentiel: https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt (vous pouvez également exécuter des benchmarks sur votre machine).

MISE À JOUR - 24.06.2018

Nest v5.0.0 Prend en charge fastify . L'intégration Fastify + Nest est encore plus performante que plain (!) Express.

La liste suivante montre ce que Nest fait par rapport au gestionnaire de routage express simple:

  • il entoure votre corps de gestionnaire d'itinéraire avec des blocs try..catch
  • il rend chaque gestionnaire de route async
  • il crée un routeur express global
  • il crée un routeur séparé pour chaque contrôleur
  • il lie le middleware de gestion des erreurs
  • il lie le middleware body-parser (à la fois json et étendu urlencoded)

Toutes les choses mentionnées reflètent un exemple du monde réel (probablement 99,9% des applications express doivent également le faire, c'est inévitable). Cela signifie que si vous souhaitez comparer les performances d'Express et de Nest, vous devez au moins couvrir les points ci-dessus. La comparaison avec l'exemple ci-dessous:

app.get('/', (req, res, next) => res.status(200).send('Hello world'));

Est injuste dans ce cas, car ce n'est pas suffisant. Lorsque je couvre ces points, voici ce que j'ai reçu (express 4.16.2):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 225.67 109.97  762
Req/Sec      4560   1034.78 5335
Bytes/Sec    990 kB 226 kB  1.18 MB

46k requests in 10s, 9.8 MB read

De plus , Nest doit:

  • reconnaître si un résultat est une valeur Promise/Observable/plain
  • en fonction du type de résultat, utilisez send() ou json() (+1 condition)
  • ajouter 3 conditions (instructions if) pour vérifier les tuyaux, les intercepteurs et les protecteurs

Il existe une sortie pour Nest (4.5.8):

Running 10s test @ http://localhost:3000
1024 connections

Stat         Avg    Stdev   Max
Latency (ms) 297.79 55.5    593
Req/Sec      3433.2 367.84  3649
Bytes/Sec    740 kB 81.9 kB 819 kB

34k requests in 10s, 7.41 MB read

Cela implique que les performances de Nest sont d'environ 79% express (-21%). Cela est dû aux raisons exposées ci-dessus et, en outre, parce que Nest est compatible avec Node 6.11.x, ce qui signifie qu'il ne peut pas utiliser asynchrone/attendre sous le capot - il doit utiliser générateurs.

Quelle conclusion tirer sur la base de ces statistiques? Aucun , car nous ne sommes pas habitués à créer des applications qui ne renvoient que des chaînes simples sans aucun élément asynchrone. Les comparaisons avec Hello world Ne veulent rien dire, c'est seulement un petit bout :)

PS. J'ai utilisé la bibliothèque autocannonhttps://github.com/mcollina/autocannon

autocannon -c 1024 -t30 http://localhost:3000

86
Kamil Myśliwiec