Node.jsバックエンドアプリケーション環境で、バリデーションは性能に大きな影響を与えるのか？
(jhyeok.com)- JavaScriptおよびNode.js環境では、バリデーションライブラリのJoiは他のライブラリより性能が遅い
- Joiを他のライブラリに置き換えると、バックエンド環境での性能向上が期待される
- バックエンドアプリケーションで有意な性能差が現れるかをテスト
- k6を使ってテストを進め、lodashとclass-transformerもあわせてテスト
- 性能テスト結果:
- native vs lodash: 性能差なし
- object literal vs class-transformer: 性能差なし
- non-validation vs Joi: Joiの遅い性能にもかかわらず、性能差は現れなかった
- 性能は重要だが、すでに進行中のプロジェクトで変更しても、投じた時間に見合うほどの性能差を感じられない可能性がある
8件のコメント
筆者は、ボトルネック状況を改善することが目的なのではなく、実運用に近い環境ではバリデーションライブラリの性能差はそれほど大きな意味を持たない、と主張しているのではないでしょうか。
本文で説明されているような I/O bound task しかないサービスではなく、CPU bound task のサービスだと仮定したらどうでしょうか?
実際の環境のサービスは、思っているより複合的です。UI を描画するのに必要なデータを配信する API だけがサーバーではありません
Validation と JSON シリアライズの処理はメインスレッドで行われる演算なので、決して軽く見てよい話ではありません。TS バックエンド界隈で最も一般的に使われているのは class-validator/class-transformer です。そしてこれらの毎秒あたりの検証可能量は 4MB 程度で、つまりメインスレッドでは毎秒 4MB を超える処理ができないという意味です。
DB の入出力はメインではなくバックグラウンドスレッドで動作するため、バックエンドサーバーの観点では（TS サーバー基準では）同時接続数に大きな影響を与えるわけではありません。サービスの性質によって一度に送信される DTO の量が大きい場合は、むしろ validation が遅いことのほうがより恐ろしいです（実際に 1 件あたりのデータが大きいサービスを作った際、NestJS の同時接続数が一桁だった事例もあります）。
同意します。筆者が「実際の状況で」と主張する前提にしては、例として挙げられている実際の状況があまりにも偏狭です。
上の方のおっしゃる通り、DB入出力がなぜ入っているのか理解しづらいベンチです。さらに、遅い validation や serialization は request DTO よりも response DTO のほうがサーバー性能に与える悪影響が大きいです。最後に、このようなベンチマーク実験をするときは DTO を1つだけ置くのではなく、さまざまな種類を用意して実験すべきです。
実際に DB I/O がなく、さまざまな構造の DTO を試した場合は、その結果が異なります。
そもそもDB接続まわりがボトルネックのように思えるので、テーマ設定が間違っているのではないかと思います
まるで性能向上がないのにあるかのように見せているようにも思えますが、実際にはそもそもDB側がボトルネックなのに、ボトルネックではない箇所の改善を中心に書かれていて、誤解を招きそうですね
ほとんどの環境でパフォーマンス向上はボトルネックを解消することを意味します。バリデーションを最適化する際は、バリデーション側がボトルネックだと特定された後であるべきでしょう。