サーバーからクライアントへの永続的な「プッシュ」通信のためにMSMQを検討していました。サーバーごとに最大1000のクライアントが存在する可能性があります。
テストの1つでは、300のオフラインクライアントに小さなメッセージを送信してから、オンラインクライアントにメッセージを送信しました。MSMQが配信不能メッセージ（MMCを介して監視）を処理したため、最後のメッセージは40分以上遅延しました。また、MSMQを適切に機能するリターンパスに使用します。
オフラインホストへの接続を試行する時間を短縮することで、MSMQをこの使用パターンに適合させる方法はありますか？そうでない場合は、他に適したキューイング製品はありますか、それとも自分の時間をロールバックしますか？生のスループットは優先事項ではありませんが、クライアント（かなり古いマシンである可能性があります）のメモリフットプリントと同様に、送信キューの数と予測可能性/最大遅延が優先されます。
ジャーナリングを無効にしてメッセージを回復不能にすることでパフォーマンスを向上させることができます...メッセージが失われることを気にしない場合。
オフライン シナリオでの簡単な解決策は、送信キューごとにスレッドを使用する MSMQ で使用できるスレッドの数を増やすことです。オフライン接続の試行ごとに時間がかかり、スレッドがブロックされます。http://technet.microsoft.com/en-us/library/cc957498.aspx できるだけ多くのスレッドを投げてみてください。
私の同僚は ActiveMQ を使用しており、より優れたパフォーマンスを発揮しながら、はるかに柔軟であると述べています。私は個人的にそれを扱ったことはありませんが、もしあなたが .Net に縛られていなければ調べてみます。
私たちの解決策は、MSMQ の管理 COM インターフェイスの 1 つを介して、オフラインのマシンへのキューをプログラムで一時停止することでした (クライアントが起動しているかどうかを知らせる UDP メッセージが既にありました)。
既知の切断されたホストへのキューを一時停止すると、MSMQ が配信不能メッセージの処理に費やす時間が大幅に短縮されました。
また、技術を評価するためのテストを考える際に、横方向の思考を適用することも良い教訓になりました。一般に、この問題のため、サーバーからクライアントへの通信に MSMQ をお勧めしません。クライアントによるポーリングが望ましいと思います。