このシナリオは有効なストレステストですか？

Question

クライアントリクエストをさまざまな方法で処理するサーバーアプリケーションがあります。

最小限の待ち時間で何人のユーザーにサービスを提供できるかを知りたいので、ユーザーのリクエストをシミュレートする小さなストレステストアプリケーションを作成しました。同時に別のアプリケーションがメモリ/ CPU使用率を監視します。

ストレステストツールは、すべてのスレッドがユーザーを表すスレッドを毎秒作成します。 リソース不足のためにストレステストで新しいスレッドを作成できない場合、ストレステストツールの新しいインスタンスが起動します。

問題は、すべてのスレッドが各リクエストのレイテンシと実行中のスレッドの数をファイルに書き込むため、数分後にディスクに書き込む必要のあるスレッドがたくさんあるため、I / Oの問題が発生することですクライアントはデータのみを要求するため、この動作は実際のシナリオには存在しません。

ユーザーごとの最大遅延を測定したいのですが、どうすればこの問題を克服できますか？

PS：

ネットワークレイテンシを考慮して別のマシンで実行するという回答もありますが、これが最終的なストレステストです。現在、同じサーバでこのテストを行って、最小のレイテンシでサポートされるユーザー数を確認しています。

Answer 1

これがネットワークアプリケーションであるかどうかは明確ではありません。ネットワーク接続されている場合は、週末に全員のデスクトップを盗んでストレステストを実行することにより、ストレステストを単純にスケールできます。これは、数件のアドホックテストである場合、テストをスケーリングする最も簡単な方法です。

しかし、いくつかの簡単な改善があるように聞こえます。これが長時間のストレステストを目的としている場合、リクエストごとに新しいスレッドを作成する代わりに、作業するスレッドのプールを作成できます（さらに簡単に、自動的にスケーリングされるスレッドプールを使用できます）。したがって、テストを2000ユーザーと定義し、サーバーを破壊する2000スレッドをスピンアップします。各スレッドは基本的にテストを行うループ内にあり、繰り返します。

明確ではないもう1つの項目は、すべてのスレッドが単一のファイルを共有しようとしているのかどうかです。これをボトルネックにしない1つの方法は、プログラムがシャットダウンするまで情報をメモリに保持することです。または、ファイルの書き込みを担当するライタースレッドを起動し、他のスレッドが情報を提供します。 IOがバックアップされた場合、ライタースレッドはIOが使用可能になるまでメモリを保持するだけであり、ワーカースレッドはその間もサーバーをハンマーで操作し続けることができます。スレッドの同期が関係するため、これはうまくスケールしない可能性があるため、ワーカースレッドの一部のエントリをバッファリングし、100リクエストごとに1回だけファイルライタースレッドと同期することを忘れないでください。応答時間以上を追跡しているように聞こえないため、これは大きな問題になるとは思いません。

編集：コメントに基づく この場合、単一のスレッドを使用してIO操作を管理することをお勧めします。すべてのワーカースレッドは、ファイルに書き込む代わりに、詳細が何であれオブジェクトを作成し、それをファイルに書き込むためにキューに渡します。ロック/ロック解除を削減するには、ワーカースレッド内のキューも使用し、頻繁に同期するだけです。スレッド内の情報を交換するときは、必ずロックしてください。また、保留中のすべてのものがメモリに蓄積されるので、メモリ使用量を監視することもできます。それでもこれでioがブロックされる場合は、書き込み量を減らすか、高速のハードディスクを調整または追加することを検討します。

Answer 2

ユーザーごとの最大待機時間に関心がある場合は、スレッドでこれを収集して、テストを停止するときにすべてのスレッドが最大待機時間を書き込むようにしないでください。統計を実行して、最小/最大/分散と実行中のスレッド/ユーザーの数を計算することもできます。画面出力も更新しないでください。データの損失を恐れる場合は、頻繁にデータをディスクに書き込みます。

スレッドは、クライアント/サーバーアプリに対してこのテストを実行するのに最適ではありません。コアの数が限られているため、実際に並行して実行されるスレッドはごくわずかですが、タイムスライスが取得されます。複数のクライアントでプログラムを起動する方がはるかに優れており、ネットワーク遅延に関するいくつかの数値も提供されます。サーバーソフトウェアは、可能であれば、クライアントがLANまたはWANで実行される最終設定と同じようにハードウェアを使用できます。

明らかに、ユーザーがシミュレートするように多くのクライアントマシンを使用することはできないため、混在環境になりますが、独立したハードウェアからの同時呼び出しなどのシナリオは、コールがタイムスライスによって準シリアル化されないため、このようなストレステストに現れます。