PERSISTENT 消息的性能比 NON_PERSISTENT 消息慢得多答案

【问题标题】：PERSISTENT message have much slower performance than NON_PERSISTENT messagePERSISTENT 消息的性能比 NON_PERSISTENT 消息慢得多
【发布时间】：2012-07-03 11:21:16
【问题描述】：

我发现 PERSISTENT 消息的性能比 NON_PERSISTENT 消息慢得多。我收发non_persistent消息，表现如下。

Method      Number of Msg  Elapsed Time

    Sending   - 500 messages - 00:00:0332
    Receiving - 500 messages - 00:00:0281

我发送和接收持久消息，性能如下。

    Sending   - 500 messages - 00:07:0688
    Receiving - 500 messages - 00:06:0934

这种行为在 MQMessage 和 JMSMessage 中都会发生。

感谢所有帮助我解决问题的人。

特别感谢 Shashi、T.Rob 和 Pangea。

【问题讨论】：

7 秒内 500 条消息 = 1 秒内 71 条消息。这还不够快。
您使用的是什么版本的 Java 和 JMS 类？
Java 版本为 [ 1.6.0 ]。我认为 JMS 版本是 [1.1]。我使用 Java5 编译器。
WebSphere MQ Java 和 JMS 类将是 v5.3.x.x、v6.0.x.x、7.0.x.x、7.1.x.x 或 7.5.0.0。通常，这些在更高版本和更高版本的队列管理器中获得更高的性能。如果您使用 v7.1，则性能报告显示每秒数百条消息，使用 JMS 每秒可显示数千条消息。请参阅：bit.ly/SupptPacMP0B您的帖子中没有足够的信息来回答您所看到的差异，除了它不是典型的。
WebSphere 版本为 7.0.0.0。我将编辑我的帖子以添加生产者和消费者类。感谢您的帮助。

标签： java jms ibm-mq websphere-7 mq

【解决方案1】：

鉴于新标题，我发现我现在可以回答这个问题了。

是的，在所有其他方面都相同的情况下，持久消息总是比非持久消息花费更长的时间。不过，它们变慢的程度是高度可调的。为了获得您所看到的结果，队列管理器可能进行了许多最坏情况的调整。以下是一些适用的因素：

磁盘是本地的还是网络的。对于 100MBS 和较慢的连接与安装在旋转磁盘上的 NFS 通信，本地驱动器几乎总是快得多。（然而，使用光纤通道和电池支持的缓存控制器安装到 SAN 几乎总是比本地旋转驱动器快。）一个常见的例子是使用消费级 NAS 驱动器。与家庭 NAS 设备一样出色，吞吐量总是比本地磁盘慢。
对于本地驱动器，驱动器的速度。较新的“绿色”驱动器改变转速以节省电力。与 10k RPM 驱动器相比，即使是 7200RPM 磁盘也会出现性能下降。
对于本地驱动器，碎片程度。即使消息很小，它们也会被放入预先分配的日志文件中，这些文件可能高度分散。
将磁盘和日志文件放在同一个本地卷上。这会导致头部争用，因为在控制权返回到应用程序之前将一条消息写入两个文件。
线性原木与圆形原木。线性比较慢，因为日志格式化程序每次都必须重新分配它们。
是否使用同步点。如果在单个工作单元中写入许多消息，WMQ 可以使用缓存写入并优化扇区放置操作。只有 COMMIT 需要成为阻塞调用。

由于非持久性消息完全在内存中处理，或者最多溢出到一个磁盘文件，因此它们不受这些问题的影响。

【讨论】：

@Rob 请帮帮我：stackoverflow.com/questions/48404838/…

【解决方案2】：

我相信您的mirco-benchmarking is flawed（使用错误的基准测试机制，并且您还将 i/o（System.out.println 内的开始和结束时间计算）包含在图片中）。首先使用Google's Caliper 之类的工具来纠正数字，然后寻找答案。上次我知道（我认为是 2003 年），MQ JMS 实现是 Java MQI 类的包装器，我们必须坚持使用 Java MQI 以满足我们的最佳吞吐量。

【讨论】：

仅供参考 - 自 2003 年以来，Java/JMS 实现发生了很大变化。Java 和 JMS 现在都继承自相同的基类，并且 WMQ 现在支持原生属性，因此映射的情况要少得多。
@T.Rob 我同意，这就是我明确提到这一年的原因。但测量本身存在缺陷。
我可能应该澄清一下，我同意 cmets 关于测量的观点。 :-)

【解决方案3】：

WebSphere MQ JMS 消息携带额外的标头（称为 JMS 标头）以支持 JMS 消息传递样式。 JMSDestination、JMSReplyTo、JMSDeliveryMode、JMSType 等和提供者特定的 JMS 标头是 JMS 标头的一部分。每次发送或接收消息时都会处理这些标头。

另一方面，WebSphere MQ Java 类只发送/接收纯 WMQ 消息。 WMQ 消息将具有 MQMD，后跟消息正文。

所以你可以看到不同之处。 JMS 消息的优点是它是基于标准的，并且 JMS 消息是可互操作的。

【讨论】：

我认为这两个性能应该没有那么不同，尽管 JMS 结构有更多的标头。是否可以将导致延迟的 JMS 消息映射到 WMQ 消息？
同意。虽然Shashi 的观点是正确的，但差异似乎非凡。
@Shashi，这个答案表明 OP 报告的差异是合法的，而不是合法的。标头不会导致两个数量级的性能差异。
@LwinHtooKo 不，消息的映射不会导致两个数量级的差异。如果我不得不猜测，那将是您没有全新安装 WMQ 客户端（即您只是抓取了 jar，而不是运行安装程序）并且 jar 文件不匹配，或者您有 CLASSPATH 问题。