パフォーマンスについては、レイテンシー (アプリケーションの応答性) とスループット (間隔ごとの操作数) の 2 つを見ています。レイテンシについては、許容できるベンチマークが必要です。スループットについては、許容可能な最小スループットが必要です。
これらはあなたの出発点です。インターバルごとに実行できる xyz の数をクライアントに伝えるには、ハードウェアとソフトウェアの構成を知る必要があります。生産ハードウェアを知ることは、正確な数値を得るために重要です。ハードウェア構成がわからない場合は、図をテスト ハードウェアから最終的な製品ハードウェアにマッピングする方法を考案する必要があります。
ハードウェアの知識がなければ、絶対的なパフォーマンスではなく、時間の経過に伴うパフォーマンスの傾向しか観察できません。
ソフトウェア構成を知ることも同様に重要です。クラスタ化されたサーバー構成はありますか?負荷分散されていますか?サーバー上で他に何かが実行されていますか? ソフトウェアをスケーリングできますか、それとも需要を満たすためにハードウェアをスケーリングする必要がありますか?
サポートできるクライアントの数を知るには、標準的な一連の操作を理解する必要があります。簡単なテストとして、クライアントを削除してスタブ クライアントを作成し、できるだけ多くのクライアントをスピンアップします。それぞれをサーバーに接続します。最終的にサーバー接続リソースの制限に達します。接続プーリングまたはより優れたハードウェアがなければ、これより高くすることはできません。多くの場合、ここより前にアーキテクチャの問題に遭遇しますが、いずれの場合も上限があります。
この情報を使用して、クライアントが実行できるスクリプトを設計します。予想されるユーザーがアクションを実行するのにかかる時間に関して、スクリプトがアクションを実行するのにかかる時間をマッピングする必要があります。上記のように数を増やし始めて、クライアントの増加がパフォーマンスの大幅な低下を引き起こすポイントに到達します。
ストレス テストにはさまざまな方法がありますが、重要なのは予想される負荷を理解することです。クライアントに期待することを尋ねます。間隔ごとに予想される需要は? そこから、上部負荷を計算できます。
多くのクライアントを何時間または何日も連続して動作させて、浸漬テストを実行できます。できるだけ多くのクライアントをできるだけ早く接続して、サーバーが高い要求 (DOS 攻撃) をどれだけうまく処理できるかを確認できます。
同時検索は、クライアントに代わって動作する標準的な動作検索を介して実行する必要があります。または、多くのスレッドで待機するセマフォを確立するスクリプトを記述してから、それらを一度にすべて解放することができます。これは楽しく、データベースを罰します。検索を実行するときは、存在する可能性のあるキャッシュ レイヤーを考慮する必要があります。キャッシュを使用する場合と使用しない場合の両方をテストする必要があります (全員が一意の検索要求を行うシナリオで)。
データベース ストレージは物理スペースに基づいています。フィールドの長さと予想されるデータの母集団から行のサイズを決定できます。これを統計的に推定するか、データ生成スクリプト (負荷テストのシナリオに役立ち、組織の資産となるはずです) を作成してから、生成されたデータをビジネス オブジェクトにマップします。クライアントは保存できる「ビジネス オブジェクト」の数を気にしますが、あなたは保存できる生データの量を気にします。
その他の考慮事項: 予想される可用性は? サーバーをオンラインにするのにかかる時間はどうですか。一度ダウンしてオンラインに戻るのに 2 日かかる場合、99.9% の可用性は良くありません。反対に、再起動に 5 秒かかり、転倒した場合は、可用性が低くても問題ありません。