サーバー間通信用MSMQ

Question

永続的な「プッシュ」サーバーからクライアント通信へのMSMQを検討していました。サーバーあたり最大1000のクライアントが存在する可能性があります。

私たちのテストでは、300人のオフラインクライアントに小さなメッセージを送信してから、オンラインクライアントにメッセージを送信しました。最後のメッセージは、MSMQが配信不能メッセージ（MMCを介して観察された）を介して処理されたため、40分以上遅延しました。 MSMQは、正常に動作するリターンパスにも使用します。

オフラインホストに接続しようとする時間を短縮することで、MSMQをこのパターンに適合させる方法はありますか？ そうでない場合は、他のキューイング製品が適していますか、それとも自分の時間を費やすのでしょうか？ Rawスループットは優先事項ではありませんが、クライアント（かなり古いマシン）にメモリフットプリントがあるのと同様に、送信キュー数と予測可能性/最大遅延時間もあります。

Answer 1

私たちのソリューションは、MSMQの管理COMインターフェイスの1つを使用して、オフラインになっているマシン（クライアントが起動しているかどうかを確認するUDPメッセージを既に持っていました）にキューをプログラムによって一時停止することでした。

既知の切断されたホストへのキューを一時停止すると、MSMQは配信不能なメッセージを処理する時間を大幅に短縮しました。

技術評価のためのテストを考えているときに、少しの横向きの考え方を適用するのもいいレッスンでした。一般的には、この問題のために、クライアントからサーバーへのMSMQの送信はお勧めしません。クライアントによるポーリングが望ましいと思います。

Answer 2

メッセージが失われても気にしない場合は、ジャーナリングを無効にしてメッセージを回復不能にすることで、パフォーマンスを向上させることができます。

オフラインシナリオでの迅速な修正は、発信キューごとにスレッドを使用するMSMQで使用できるスレッドの数を増やすことです。各オフライン接続の試行にはしばらく時間がかかり、スレッドがブロックされます。 http://technet.microsoft.com/en-us/library/cc957498.aspxできるだけ多くのスレッドを投げてみてください。

私の同僚は、ActiveMQを使用しており、パフォーマンスが向上しているとはるかに柔軟性があると言いました。私は個人的にそれを使っていませんが、あなたが.Netに縛られていないなら、私はそれを調べます。