ストアドプロシージャのスケーラビリティのテスト
各ページが読み込まれるたびに、指定されたユーザーの新しいメッセージの数をUIに配信するために呼び出される電子メールアプリケーションがあります。 DBレベルでテストしているものにはいくつかのバリエーションがありますが、すべてストアドプロシージャコールによって抽象化されています。
私は、限界点（1秒あたりの要求数）がどうなるかを確認するために、DBを非難しようとしています。
簡単に言うと、userIdにクラスター化インデックスを持つ、このuserId、newMsgCountなどのテーブルがあります。 SQLは、毎秒数百または数千のこれらの応答を処理できる必要があります。私は遅れているのは私の.NETアプリだと思います。
これをSQLパフォーマンスに基づくテスト結果を達成するための良いテストにするにはどうすればよいですか？
これにDBを追加するためのストアドプロシージャ名とパラメーターを指定できるツールはありますか？
DBが分を返すことができるかどうかを確認したいと思います。 1秒あたり250応答。
SQLQueryStressは小規模の同時実行性テストに最適なツールですが、負荷テストの仕事は実際にはありません。驚くほどほとんど知られていないツールセットがMicrosoftから無料で入手でき、ほとんどのSQL Serverストレステストシナリオ RMLユーティリティ に対応できます。
ツールの非常に簡単な概要：
- ReadTraceは、プロファイラートレースを.trcファイルから.rml（再生マークアップ言語）に変換します。
- OStressは、サーバーに対して.rmlおよび.sqlファイルを再生するために使用されます。
- [〜＃〜] orca [〜＃〜]（OStress Replay Control Agent）は、OStressの分散インスタンス全体の再生を調整します。
- Reporterは、パフォーマンス分析レポートを提供します。
サンプルデータベースとワークロードを含むSQLCatチームからの優れた高速スタート記事があります RMLユーティリティ9.0を使用したMicrosoft SQL Serverの精度パフォーマンス
再生のためのプロファイリングアクティビティ、または場合によってはシナリオに適した.sqlスクリプトのセットを手動でクランクし、OStressとORCAを介して再生するオプションがあります。
負荷テストとパフォーマンスの問題の調査の両方に適したツール。
使用できるツールの1つは SQLQueryStress です。クイックスタートでは、ストアドプロシージャの反復とスレッド数を提供します。次に、ストレステストを開始します。 CPU秒数、論理読み取りなどのメトリックが表示されます。
あなたは.NET開発者のようですね。 1つの方法は、マルチスレッドを使用し、データベースとストアドプロシージャに対して一定量の同時ヒットを行う小さなアプリケーションを作成することです。これが起こっている間にトレースを実行します。
SQL Serverの負荷を自動的に増やしたい場合は、特定の間隔で並行スレッドの量を増やすアプリケーションコードを記述します。
それが私のやり方です。