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