WebSphere MQ性能

arr*_*man 3 performance jms mq ibm-mq

我在机器1中运行MQ服务器7.1.我有一个在机器2中运行的Java应用程序,它使用JMS将消息写入机器1中的队列.java应用程序每秒处理数百条消息(来自其他地方的数据).目前,200条文本消息(平均大小为600字节)或每秒2000条消息将消息写入队列大约需要100毫秒.这是合理的表现吗?为了进一步提高性能,可以采取哪些措施.即更快?

T.R*_*Rob 8

WebSphere MQ性能报告中提供了许多详细的建议.这些发布为SupportPacs.如果您从SupportPac登录页面开始,那么您想要的那些名称都是MPxx,并且每个平台和每个版本都可用.

正如您将从SupportPacs中看到的那样,WMQ开箱即用,可以在各种消息大小和类型之间实现速度和可靠性的平衡.调整配置和设计/架构有相当大的自由度.

从配置角度来看,存在用于持久性和非持久性消息的缓冲区,用于减少从三次写入到单次写入的磁盘写入完整性,调整日志文件大小和数量,连接多路复用等等的选项.您可以从中可以推断,QMgr调整到特定的流量特征越多,你就能越快得到它.另一方面,如果出现一种超出调整规范的新型流量,那么QMgr会严格调整.

我还看到了将WMQ文件系统分配给单独的主轴的巨大性能提升.写入持久性消息时,它会同时发送队列文件和日志文件.如果这两个文件系统都争用相同的磁盘读/写磁头,则会降低性能.这就是为什么WMQ有时在高性能笔记本电脑上运行速度比在大小相同的虚拟机或服务器上慢.如果笔记本电脑具有物理旋转磁盘,其中WMQ文件系统都已分配且服务器具有SAN,则无法进行比较.

从设计的角度来看,并行性可以获得很多性能.性能报告显示,添加更多客户端连接可显着提高性能,直至达到平衡并最终开始下降的程度.幸运的是,在它崩溃之前的最大客户端数量非常大,并且Web应用服务器通常在WMQ之前停滞不前,只需要从所需的Java线程数量开始.

可以产生重大影响的另一个实现细节是提交间隔.如果应用程序是这样的,可以一次放入或获取许多消息,这样做可以提高性能.在COMMIT发生之前,不需要将同步点下的持久性消息刷新到磁盘.在单个工作单元中编写多个消息允许WMQ更快地将控制返回到程序,缓冲写入,然后比一次写入一条消息更有效地优化它们.

The Mice and Elephants文章包含对调优选项的深入讨论.它是developerWorks Mission:Messaging系列的一部分,其中包含一些其他文章,这些文章也涉及调优.

  • 通过"提交间隔",我只是在讨论应用程序在发出`COMMIT`之前读取和/或写入了多少消息,而不是MQ设置.某些应用程序(如请求/回复)最适合在一个工作单元中使用一条消息.但是对于像批量加载或转换这样的东西,可以读取消息,写出结果消息并循环,只为每x次迭代发出`COMMIT`.由于DB每个事务处理好100个更新,因此显而易见的是在XA事务中包含WMQ消息,导致WMQ提交间隔为100. (2认同)