我们正在研究 MSMQ 以实现持久的“推送”服务器到客户端的通信。每台服务器最多可以有 1000 个客户端。
在我们的一个测试中，我们向 300 个离线客户端发送了一条小消息，然后向一个在线客户端发送了一条消息。最后一条消息延迟了 40 多分钟，因为 MSMQ 正在处理无法传递的消息（通过 MMC 观察到）。我们还使用 MSMQ 作为它运行良好的返回路径。
有没有办法通过减少尝试连接到脱机主机的时间来使 MSMQ 适应这种使用模式？如果没有，是否还有其他更适合的排队产品，或者它是你自己的时间？原始吞吐量不是优先级，但传出队列的数量和可预测性/最大延迟是优先级，客户端（可能是相当旧的机器）上的内存占用也是如此。
您可以通过禁用日志记录并使消息不可恢复来提高性能......如果您不关心消息丢失。
脱机方案的快速修复可能是增加 MSMQ 可用的线程数，它使用每个传出队列的线程。每次离线连接尝试都需要一段时间，阻塞一个线程。http://technet.microsoft.com/en-us/library/cc957498.aspx尝试向它抛出尽可能多的线程。
我的同行使用过 ActiveMQ，并表示它更灵活，同时性能更好。我没有亲自使用它，但如果你没有绑定到.Net，我会调查它。
我们的解决方案是通过 MSMQ 的管理 COM 接口之一以编程方式暂停到离线机器的队列（我们已经有一条 UDP 消息来判断客户端是否已启动）。
由于已知断开连接主机的队列暂停，MSMQ 花费更少的时间处理无法传递的消息。
在考虑评估技术的测试时应用一点横向思维也是一个很好的教训！一般来说，由于这个问题，我不会推荐将 MSMQ 用于服务器到客户端的通信——我会说由客户端轮询会更好。