私たちは Node.js が非常に高速なパフォーマンスであることを理解しています。 しかし、他の言語と同様に、ユーザーにとって望むよりも悪いパフォーマンスをする Node.js コードを書くことができます。 これに対処するために、適切なパフォーマンステストが必要です。
アプリケーションのパフォーマンスをテストする方法を理解する最善の方法は、例を通して歩くことです。
Node.js は、タスク実行用のスクリプトを書いたり、Web サーバーを実行したり、Web サイトなどの静的ファイルを提供するなど、多くの目的で使用することができます。 今日は、Node.js の HTTP Web API をテストするための手順を説明します。 しかし、もしあなたが Node で何か他のものを構築しているなら、心配しないでください – 原則の多くは似ているでしょう。
何について話しているのか。
Node.js アプリケーションの大きな考慮点は、イベント ループとして知られているものによって促進される、シングルスレッドで実行から完了する動作です。 今、私はあなたが何を考えているのか知っています。
まず、シングルスレッドについて説明します。 スレッドは、概念として、アプリケーション内で同時処理を可能にします。 Node.js には、少なくとも伝統的な意味において、この機能はありません。
イベントループ
イベントループとは何でしょうか。 これは、ハートビートのように動作します。 数ミリ秒ごとに、Node.js は新しいタスクを開始するためにワークキューをチェックします。 Node.js は数ミリ秒ごとに、新しいタスクを開始するために作業キューをチェックします。作業がある場合、これらをコールスタック上に持ってきて、完了するまで実行します (Run-to-completion については、まもなく説明します)。 つまり、1 つのタスクが待機している間に、別のタスクを開始することができます。 つまり、スレッドではなく、コールバック、プロミス、および async/await のようなプログラミング スタイルによって促進される非同期コードを使用するのです。
Okay, so you’re wondering: このすべての技術用語はパフォーマンスと関係があるのでしょうか。
説明しましょう。
Node.js パフォーマンスとイベント ループ
Node.js アプリケーションを構築し、2 つのエンドポイント (ファイルのアップロード用とユーザー プロファイルを取得するもの) があると想像してください。 ユーザー プロファイル API は、おそらくファイル アップロードよりもかなり頻繁に要求され、十分に速く応答しない場合、すべてのユーザーに対してすべてのページ ロードをブロックすることになります。 また、ユーザーはタスクのアップロードに時間がかかることを期待していますが、ページのロード時間にはあまり寛容ではありません。 イベント ループを念頭に置いてプログラムしないと、ファイルがアップロードされている間、Node.js はすべてのシステム リソースを占有することになり、他のユーザーがアプリケーションを使用するのをブロックしてしまう可能性があります – ウーン！
そしてこれが Node.js のシングル スレッドの性質を理解する必要がある理由です。 アプリケーションを変更するときに、この動作を考慮する必要があります。 ネットワークへのリクエスト、ファイルの書き込み、重い計算の実行など、長時間実行するタスクを同期的に行うことは避けたいものです。
Node.js のシングルスレッドの性質についてわかったので、それを利用しましょう。 ステップ 1: Node.js パフォーマンス テスト ツールの選択
最初に、パフォーマンス テストを実行できるツールを選択したいと思います。 そこには多くのツールがあり、すべて Node.js のパフォーマンス チューニングのために異なる長所と短所があります。 考慮すべき主な点は、たとえ Node.js アプリケーションをテストしていても、ネットワークを介して外部からパフォーマンス テストを行う場合、パフォーマンス テスト ツールが Node.js で書かれているかどうかは問題ではないことです。
基本的な HTTP パフォーマンス テストでは、私は Node.js で書かれたわかりやすいパフォーマンス テスト ツールである Artillery が好きです。 これはまた、API リクエストのパフォーマンス テストを実行するのに特に優れています。 Artillery は、あなたの負荷プロファイルを定義する設定ファイルを書くことによって動作します。 どのエンドポイントをどのような割合で、どのような時間リクエストするかなどを Artillery に伝えます。
基本的なテスト スクリプトは次のようになります。
そして、テストを実行するには、次のように実行するだけです:
artillery run your_config.yml
Artillery は、あなたが指示した数と同じだけアプリケーションにリクエストします。 これは、実稼働環境を模倣したパフォーマンステストのプロファイルを構築するのに便利です。 パフォーマンステストプロファイルとはどういう意味でしょうか？
ステップ 2: Node.js パフォーマンス テスト プロファイルを作成する
上記のように、パフォーマンス テスト プロファイルは、パフォーマンス テストがどのように実行されるかを定義したものです。 正確な Node.js パフォーマンス チューニングを行うために、可能であれば、本番トラフィックがどのように動作するか、またはどのように動作すると予想されるかを模倣したいと思うことでしょう。 例えば、イベントのウェブサイトを構築している場合、チケットをリリースする頃に多くのトラフィックが予想されるので、この挙動を模倣したプロファイルを構築したいと思います。 また、短時間で大量の負荷に対応するアプリケーションのスケーラビリティをテストしたいと思うことでしょう。 あるいは、eコマースサイトを運営しているのであれば、さらにトラフィックが増加することが予想されます。
複数のテスト プロファイルの活用
楽しくて興味深い点は、異なるテスト プロファイルを作成し、それらを重複して実行できることです。 たとえば、基本的なトラフィック レベル (たとえば、1 分あたり 100 リクエスト) を模倣するプロファイルを作成し、次に、検索エンジン広告を出した場合など、サイトへの大量のトラフィックを見た場合に何が起こるかを模倣することが可能です。 複数のシナリオをテストすることは、徹底した Node.js パフォーマンスのチューニングに重要です。
Replicating large-scale distributed systems
ここで少し注意しなければならないことがあります：アプリケーションがあるサイズに達すると、この方法で負荷を模倣しても実現可能性が失われます。 トラフィック ボリュームがあまりにも荒々しく、予測不可能で、大量である可能性があるため、リリース前にアプリケーションをテストする現実的な方法を作成するのは困難なのです。 私たちはどうすればよいでしょうか。
「おいおい、待てよ！」と思うかもしれません。 しかし、システムがあるサイズになると、異なるパフォーマンス テスト戦略を活用することが意味を持つ場合があります。 カナリア リリースのような概念を活用して、変更を実稼働環境に送り出し、一定の割合のユーザーのみでテストすることができます。 もしパフォーマンスの低下が見られたら、そのトラフィックを以前の実装に戻すことができます。 このプロセスは本当に実験を促進し、最も良いことは、実際の運用アプリケーションでテストしているので、テスト結果が運用を模倣していないという心配がないことです。
ここまでで、ツールを決定し、運用を再現するプロファイルを作成しました。 次に行うことは何でしょうか。 アプリケーションを分析するために必要なデータがあることを確認する必要があり、Node.js パフォーマンス監視およびアプリケーション パフォーマンス管理 (APM) ツールを使用してそれを行います。 APM とは何でしょうか？ 続けてお読みください。
ステップ 3: 観察可能性/監視を設定する
アプリケーションに対してパフォーマンス テストを実行し、希望と祈るだけでは望みません。 そうすると、それがどのように実行されているか、そして、私たちが考えるように実行されているかどうかを理解することができません。 ですから、テストを始める前に、次のような質問を自分自身に投げかけるべきです。 私のSLAやKPIは何なのか？ パフォーマンスの問題を効果的にデバッグするには、どのような測定基準が必要ですか。 価値のあるすべての生産アプリケーションは、何らかの形で観測および／または監視ソリューションを使用しています。 これらのツールはしばしば APM と呼ばれ、実行中のアプリケーションに関する重要な Node.js パフォーマンス メトリクスを表示できます。
APM で稼働する
APM にはさまざまな形やサイズがあり、すべて異なる機能、価格、セキュリティ影響、パフォーマンス、その他があります。 ニーズに合った最適なツールを見つけるには、少し買い物をするのが得策です。 Node.js のパフォーマンス テストを実行するときに必要な洞察とデータを提供するのは、これらのツールです。
では、アプリケーションを監視すべきことがわかった場合、正確に何を監視すべきでしょうか。 7909>
- 集約されたログ-アプリケーションのログは、いくつかのライブラリによって暗黙的に、または開発者によって明示的に出力され、アプリケーションに対する洞察を得るために使用されます。 ほとんどのログ集計ツールは、ログに記録されたデータを簡単に検索し、視覚化することができます。 私たちの場合、各 API のパフォーマンスをログアウトし、それらをグラフにプロットすることができました。
- インフラストラクチャの洞察-アプリケーションはある種のホスト上で実行されるので、おそらくすべてのデータを見たいと思うことでしょう。 クラウドで実行している場合、ほとんどのプロバイダーは、このデータを (粗い形式ではありますが) そのまま提供します。 これらのツールから得られるデータは、ホストの CPU やメモリ使用量、接続データなどをカバーします。
- Application monitoring – このタイプのツールは通常アプリケーション コード内に置かれ、関数がどのように実行/呼び出しされているか、どんなエラーが発生したかなどについての洞察を得ることができます。 要件に応じて、すべてを行う 1 つのツール、または異なる目的のための一連のツールを必要とするかもしれません。
Node.js に合わせたツール
ツールに加えて、関数実行を見たり、イベント ループ実行に関するデータを抽出する、他の Node.js 専用ツールおよびフレーム グラフなどのプロファイラーも含まれることがあります。 Node.jsのパフォーマンステストに精通するにつれ、データに対する要件は増える一方です。
さて、ツールをセットアップし、パフォーマンスの現実的なプロファイルを取得し、アプリケーションのパフォーマンスを理解したので、テストを実行する準備はほぼ整いました。 しかし、その前にもう 1 つのステップがあります。テスト インフラストラクチャを作成することです。
ステップ 4: Node.js パフォーマンス テスト インフラストラクチャの作成
望めば、自分のマシンからパフォーマンス テストを実行できますが、これを行うには問題があります。 これまでのところ、たとえば、テスト プロファイルを使用して、パフォーマンス テストが確実に複製されるように懸命に努力してきました。 テストを複製するもう 1 つの要因は、常に同じインフラストラクチャ (マシン) でテストを実行することです。
一貫したテスト インフラストラクチャを実現する最も簡単な方法の 1 つは、クラウド ホスティングを活用することです。 テストを起動するホスト/マシンを選択し、テストを実行するたびに、常に同じマシンから、できれば同じ場所から、リクエストの遅延に基づくデータの歪みを回避することを保証します。 このアイデアを「コードとしてのインフラストラクチャ」と呼びます。 ほとんどのクラウド プロバイダーはこれをネイティブにサポートしていますし、Terraform のようなツールを使用して支援することもできます。
ステップ 5: テストを実行する！
最後のステップは、テストを実際に実行することです。 コマンドライン設定を開始すると (ステップ 1 で行ったように)、Node.js アプリケーションへのリクエストが表示されます。 モニタリング ソリューションを使用して、イベント ループがどのように機能しているか、特定の要求が他の要求よりも時間がかかっているか、接続がタイムアウトしているかなどを確認できます。
パフォーマンス テストのケーキの仕上げは、それらをビルドおよびテスト パイプラインに置くことを検討することです。 これを行う 1 つの方法は、毎朝それらをレビューできるように、パフォーマンス テストを夜間に実行することです。 Artillery は、これらのレポートを作成するための素晴らしくシンプルな方法を提供し、Node.js のパフォーマンスの後退を発見するのに役立ちます。
本日は、イベント ループが JavaScript アプリケーションのパフォーマンスに与える影響、パフォーマンス テスト ツールの選択方法、Artillery で一貫したパフォーマンス テスト プロファイルを設定する方法、Node.js を診断するために設定したい監視方法について説明しました。Node.js のパフォーマンスの問題を診断するためにどのような監視を設定するか、そして最後に、あなたとあなたのチームにとって最大の価値を得るために、パフォーマンス テストをいつ、どのように実行するかについて説明します。 今、あなたは Node.js のパフォーマンス機能を活用し、ユーザーが好む超高性能なアプリケーションを書くために必要なすべてを手に入れました！
。