我们正在寻找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用于服务器到客户端的通信,因为这个问题 - 我会说客户端轮询会更好。