web-dev-qa-db-ja.com

nestjsとプレーンエクスプレスパフォーマンス

Getリクエスト(データベースなし)でテキストを返す単純なネストのコントローラーでパフォーマンスをテストしました。 Expressと同じシンプルなGETコントローラー(ミドルウェア)。

WRKツールを使用してパフォーマンスをテストしました。

その結果、プレーンエクスプレスはnestjsより2倍高速です。 nestjsがそんなに多くのオーバーヘッドを作成するのはなぜですか?

18
Shadowfax

更新-22.09.2018

ベンチマークディレクトリがリポジトリに追加されました: https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt (マシン上でもベンチマークを実行できます)。

更新-24.06.2018

ネスト_v5.0.0_は fastify をサポートします。 Fastify + Nest統合は、plain(!)expressよりもさらにパフォーマンスが高くなります。


次のリストは、Nestがプレーンエクスプレスルートハンドラと比較して実行していることを示しています。

  • ルートハンドラー本体をtry..catchブロックで囲みます
  • すべてのルートハンドラをasyncにします
  • グローバルエクスプレスルーターを作成します
  • 各コントローラーに個別のルーターを作成します
  • エラー処理ミドルウェアをバインドします
  • _body-parser_ミドルウェア(jsonと拡張urlencodedの両方)をバインドします

上記のものはすべて、現実世界の例を反映しています(おそらく99.9%のエクスプレスアプリもこれを行う必要があり、避けられないでしょう)。つまり、ExpressとNestのパフォーマンスを比較する場合は、少なくとも上記のポイントをカバーする必要があります。以下の例との比較:

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

この場合、それは十分ではないため、不公平です。これらのポイントをカバーするとき、これは私が受け取ったものです(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
_

さらに、Nestは以下を行う必要があります:

  • 結果がPromise/Observable/plain値であるかどうかを認識します
  • 結果のタイプに基づいて、send()またはjson()(+1条件)を使用します
  • パイプ、インターセプター、ガードをチェックする3つの条件(ifステートメント)を追加します

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
_

これは、ネストのパフォーマンスが約79%エクスプレス(-21%)であることを意味します。これは、上記で説明した理由によるものです。さらに、NestはNode 6.11.xと互換性があり、フードの下でasync/awaitを使用できないことを意味します。ジェネレーター。

これらの統計に基づいて、どの結論を導き出しますか? None。非同期のものなしでプレーンな文字列のみを返すアプリケーションの作成には慣れていないためです。 _Hello world_との比較は何も意味せず、単なるビットです:)

PS。 autocannonライブラリを使用しました https://github.com/mcollina/autocannon

_autocannon -c 1024 -t30 http://localhost:3000_

86