4

我发现 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。

4

3 回答 3

4

鉴于新标题，我发现我现在对这个问题有了回应。

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

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

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

于 2012-07-04T17:32:56.020 回答
1

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

于 2012-07-04T03:01:13.717 回答
0

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

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

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

于 2012-07-03T03:51:08.083 回答