2

アプリケーションに SSB メッセージング ソリューションを実装しましたが、スケーリングの問題が発生しています。SSB アプリケーションのスケールアップの経験をお持ちの方で、私たちが間違っている可能性があることについて何か提案をいただけますか?

セットアップは、アクティブ化されたプロシージャを単一のターゲット キューに供給する単一のイニシエータ キューを使用することです。アクティブ化されたプロシージャは、受信したメッセージを処理し、関連するタイプのメッセージを登録したクライアントに選択的にディスパッチします。

この第 2 段階のディスパッチでは、単一のイニシエーター キュー (最初のメッセージ インジェクションに使用されたものとは異なります) が再び使用され、適切であると判断された任意の数のクライアント キューにメッセージが送信されます。

各クライアントは、他のすべてのクライアントに送信されるメッセージを作成するデータベースに対して操作を実行するため、N^2 スケーリングの問題です。比較的少数のクライアント (10 以下) の場合、これは問題になりませんが、N=35 または N=40 の範囲にスケールアップすると、メッセージを処理できるよりも速くエンキューし始めます。ワークフローのポイントであり、重大な遅延の問題が発生し始めます。ただし、失敗している負荷は、SSB 実装のベストケース パフォーマンスとして報告されているものをまだかなり下回っているため、実装に欠陥があると確信しています。

関連する診断には次のものがあります。

  1. 私たちのサーバーには、これまでに見た中で最も負荷の高いクライアント負荷の下でも、メッセージがキューにバックアップされている間でも、十分な CPU、I/O、およびネットワーク帯域幅が利用可能です。
  2. アクティブ化されたプロシージャの 5 つのコピーから 512 のコピーまで、どこでもアクティブ化できるようにシステムを構成しましたが、スループットとエンド ユーザーのパフォーマンスにはほとんど影響がありません。
  3. アクティブ化されたプロシージャは、一度に複数のメッセージを処理し、いくつかの穏やかな XML クエリといくつかの小さなデータベース テーブルに対する SELECT を使用してそれらを処理します。この手順は無負荷状態でテストされており、オーバーヘッドはわずかです。
  4. LCK_M_X、PAGELATCH_SH、PAGELATCH_EX、および WRITELOG 待機のパーセンテージが高いことを示しています (これらは上位 4 つの違反者です)。
  5. 最も重い負荷の下で見られる RECEIVEs/sec よりも約 2 倍の SENDs/sec を示しています。

構成を高速化するために何ができるかを考えている人にとって役立つ診断が他にある場合は、おそらくそれらを見つけることができます。

4

1 に答える 1

6

最も重い負荷の下で見られる RECEIVEs/sec よりも約 2 倍の SENDs/sec を示しています。

これが問題の核心だと思います。カウンターは、メッセージではなく、ステートメントの実行率を測定します。これは、RECEIVE が各結果セットでおそらく 1 つまたは 2 つのメッセージしか受信しないことを意味します。会話グループのロックにより、RECEIVE は返される結果ごとに 1 つの会話グループのみを取得するように制限されています。キューに数千の利用可能なメッセージがあっても、それらがすべて別々の会話にある場合、RECEIVE は 1 つだけを返します。あなたが説明したように、通常はパフォーマンスが低下し、症状が発生します。

高いスループットを達成するには、問題のあるキューで RECEIVE が重要な結果セットを生成できるように、何らかの方法でメッセージをいくつかの会話に属するようにする必要があります。これを実現する方法は、ビジネス ワークフローの詳細によって異なります。

于 2013-05-11T18:07:43.493 に答える