0

Azure Queue バックエンドで NServiceBus をテストしています。すべてのデフォルト設定を使用して NServiceBus を構成し、次のコードを使用してメッセージを送信します。

while ((data = Console.ReadLine()) != null)
{
   Stopwatch sw = new Stopwatch();
   sw.Start();
   Bus.Send("testqueue", new Message() {Data = data});
   sw.Stop();
   Console.WriteLine("Sent time: " + sw.ElapsedMilliseconds);
}

私の開発マシンで実行すると、メッセージをキューに送信するのに約 700 ミリ秒かかります。Azure Storage クライアントを使用して直接書き込む場合、キューは遠く離れており、最大 350 ミリ秒です。

今、私は2つの質問があります:

  1. Bus.Send 呼び出しでスレッドをブロックしたくありません。1 つのオプションは、async\await パターンを使用することです。別のオプションは、0MQ と同様に、メッセージを配信するためのメモリ内キューを持つことです。もちろん、最後のオプションは配信を保証するものではありませんが、いくつかの監視機能があると仮定すると、私はそれを受け入れることができます.
  2. メッセージの送信に、キューへの単純な書き込みの 2 倍の時間がかかるのはなぜですか? これは最適化できますか？
4

1 に答える 1

0

データ プロパティのサイズは?

このテストを自分で実行したところ (文字列「Whatever」をデータとして使用)、リモート送信ごとに平均 50 ミリ秒の遅延が発生し、15 秒ごとにスロットルが発生し、その時点で呼び出しに約 300 ミリ秒かかります (これは予想されることです)。 ）。

Azure Storage はリモートの http ベースのサービスであるため、距離による遅延の影響を受けることに注意してください。私の知る限り、ここでもパフォーマンス目標は公開されていません。さらに、データが移動されているときにプッシュバックするアクティブなスロットリングがあり、これは約 15 秒ごとに発生します (舞台裏で何が起こっているかを理解するには、私のストレージ内部の話を参照してください。http://www.slideshare.net/YvesGoeleven /azure-storage-deep-dive )

async/await のトピックについて。あなたの目的がUIスレッドのブロックを解除することである場合は、先に進んでこのようにしてください...

await Task.Factory.StartNew(() => _bus.Send(new Message{
       Whatever = data
})).ConfigureAwait(false);

目的がより高いスループットを達成することである場合は、代わりに、より多くの送信スレッドを使用する必要があります。これは、スレッドが http 応答を待機する必要があるためです。これは、送信スレッドまたは async/await から起動されたバックグラウンド スレッドのいずれかです。ただし、使用する送信脅威の数に関係なく、すべてのキューも個別に (数百のメッセージ/秒で) 調整されることに注意してください。

PS: IT は、.net サービスポイント マネージャーの次の設定を変更して、多数の小さな http 要求に合わせて最適化することもお勧めします。

ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false;
ServicePointManager.DefaultConnectionLimit = 48;

お役に立てれば...

于 2014-07-09T08:52:50.430 に答える