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