ストアドプロシージャのスケーラビリティのテスト

各ページの読み込みで特定のユーザーの新しいメッセージの数をUIに配信するために呼び出される電子メールアプリケーションがあります。DBレベルでテストしているものにはいくつかのバリエーションがありますが、すべてストアドプロシージャコールによって抽象化されています。

私は、ブレークポイント（1秒あたりのリクエスト数）がどうなるかを確認するために、DBを強打しようとしています。

一言で言えば、このuserId、newMsgCountなどのテーブルとuserIdのクラスター化インデックスがあります。SQLは、1秒あたり数百または数千のこれらの応答を処理できる必要があります。遅れは私の.NETアプリだと思います。

SQLパフォーマンスに基づいてテスト結果を達成するために、これをどのように良いテストにすることができますか？

これには、ストアドプロシージャ名とパラメーターを指定してDBをパンドするツールがありますか？

DBが1分を返すことができるかどうかを見たいです。1秒あたり250応答。

SQLQueryStressは、小規模の同時実行性テストに最適なツールですが、実際には負荷テストの仕事ではありません。ほとんどのSQL ServerストレステストシナリオであるRMLユーティリティに対応できる、驚くほど少ない既知のツールセットがMicrosoftから無料で入手できます。

ツールの非常に簡単な概要：

• ReadTraceは、プロファイラートレースを.trcファイルから.rml（リプレイマークアップ言語）に変換します。
• OStressは、サーバーに対して.rmlおよび.sqlファイルを再生するために使用されます。
• ORCA（OStress Replay Control Agent）は、OStressの分散インスタンス間でリプレイを調整します。
• Reporterはパフォーマンス分析レポートを提供します。

サンプルデータベースとワークロード、RML Utilities 9.0を使用したMicrosoft SQL ServerのPrecision Performanceを含む、SQLCatチームによる優れたファーストスタート記事があります。

再生用のプロファイリングアクティビティ、またはシナリオにより適切な場合は、一連の.sqlスクリプトを手動でクランクしてから、OStressおよびORCAを介して再生するオプションがあります。

負荷テストとパフォーマンス問題の調査の両方に最適なツール。

使用できるツールの1つはSQLQueryStressです。クイックスタートのために、ストアドプロシージャ、反復、スレッド数を提供します。次に、ストレステストを開始します。CPU秒、論理読み取りなどのメトリックが表示されます。

あなたは.NET開発者のようですね。1つの方法は、マルチスレッドを使用し、データベースとストアドプロシージャに対して一定量の同時ヒットを持つ小さなアプリケーションを作成することです。これが発生している間にトレースを実行します。

SQL Serverの負荷を自動的に増加させる場合は、特定の間隔で同時スレッドの量を増やすアプリケーションコードを記述します。

それは私がそれについて行く方法です。