我在 machine1 中运行 MQ 服务器 7.1。我有一个在机器 2 上运行的 java 应用程序，它使用 JMS 将消息写入机器 1 中的队列。java 应用程序每秒处理数百条消息（数据来自其他地方）。目前，200 条文本消息（平均大小 600 字节）或每秒 2000 条消息将消息写入队列大约需要 100 毫秒。这是合理的表现吗。可以做些什么来进一步提高性能。即更快？
问问题
6374 次
2 回答
8
WebSphere MQ 性能报告中提供了许多详细的建议。这些以 SupportPacs 的形式发布。如果您从SupportPac 登录页面开始，您想要的所有页面都名为 MPxx，并且可用于每个平台和每个版本。
正如您将在 SupportPacs 中看到的那样，开箱即用的 WMQ 已针对各种消息大小和类型的速度和可靠性进行了调整。通过配置和设计/架构进行调整有相当大的自由度。
从配置的角度来看，有持久性和非持久性消息的缓冲区、将磁盘写入完整性从三次写入降低到一次写入的选项、日志文件大小和数量的调整、连接多路复用等。你可以由此推断，QMgr 越是针对特定的流量特征进行调整，您就可以越快地运行它。不利的一面是，如果出现了超出调整规范的新型流量，那么经过严格调整的 QMgr 往往会做出不良反应。
我还看到了将 WMQ 文件系统分配给单独的主轴的巨大性能改进。当写入持久消息时，它会发送到队列文件和日志文件。如果这两个文件系统都在争用相同的磁盘读/写磁头，这会降低性能。这就是为什么 WMQ 在高性能笔记本电脑上的运行速度有时会比在大致相同大小的虚拟机或服务器上运行得慢的原因。如果笔记本电脑有物理旋转磁盘，同时分配了 WMQ 文件系统并且服务器有 SAN，则没有可比性。
从设计的角度来看，并行性可以获得很多性能。性能报告显示，添加更多客户端连接可显着提高性能，直至达到一定程度，然后趋于平稳并最终开始下降。幸运的是，在它下降之前的客户端数量非常大，并且 Web 应用程序服务器通常在 WMQ 之前就陷入困境，这仅取决于所需的 Java 线程数量。
另一个可以产生重大影响的实现细节是提交间隔。如果应用程序可以一次放置或获取许多消息，那么这样做可以提高性能。同步点下的持久消息在发生之前不需要刷新到磁盘COMMIT。在单个工作单元中写入多条消息允许 WMQ 更快地将控制权返回给程序，缓冲写入，然后比一次写入一条消息更有效地优化它们。
Of Mice and Elephants文章包含对调优选项的其他深入讨论。它是 developerWorks Mission:Messaging系列的一部分，其中包含一些其他文章，也涉及调优。
于 2012-02-01T19:12:16.507 回答
1
于 2014-01-13T06:20:01.103 回答