4

I found that PERSISTENT message have much slower performance than NON_PERSISTENT message. I sent and received non_persistent messages and the performance is as follows.

Method      Number of Msg  Elapsed Time

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

I sent and received persistent messages and the performance is as follows.

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

This behavior happens in both MQMessage and JMSMessage.

Thank all people helping me out the problem.

Special thanks to Shashi, T.Rob and Pangea.

Lwin Htoo Ko
  • 2,326
  • 4
  • 26
  • 38
  • 500 messages in 7 seconds = 71 messages in 1 second. That is not fast enough. – Lwin Htoo Ko Jul 03 '12 at 10:14
  • What version of Java and JMS classes are you using? – T.Rob Jul 03 '12 at 21:02
  • Java version is [ 1.6.0 ]. I think JMS version is [ 1.1 ]. I used Java5 compiler. – Lwin Htoo Ko Jul 04 '12 at 01:51
  • WebSphere MQ Java and JMS classes would be v5.3.x.x, v6.0.x.x, 7.0.x.x, 7.1.x.x or 7.5.0.0. As a rule, these get more performant in later versions and against a later version queue manager. If you use v7.1, the Performance Report shows hundreds of messages per second up to thousands of messages per second using JMS. See: http://bit.ly/SupptPacMP0B There is nowhere enough info in your post to provide an answer as to the difference you are seeing other than that it is not typical. – T.Rob Jul 04 '12 at 02:19
  • WebSphere Version is 7.0.0.0. I will edit my post to add producer and consumer classes. Thanks for the help. – Lwin Htoo Ko Jul 04 '12 at 02:26
  • This is an old question but this [link](https://docs.oracle.com/cd/E19879-01/821-0027/aeojo/index.html) clarifies the matter a bit. – Sabir Khan Jun 16 '16 at 06:46

3 Answers3

4

Given the new title, I find I now have a response to this question.

Yes, persistent messages will always take longer than non-persistent messages with all other aspects being equal. The degree to which they are slower is highly tunable, though. In order to get the results that you are seeing it is likely that the queue manager has many of the worst-case tunings. Here are some of the factors that apply:

  • Whether the disk is local or networked. For 100MBS and slower connections talking to NFS mounted over spinning disks, a local drive is almost always much faster. (Mounts to SAN with fiber channel and battery-backed cached controllers are nearly always faster than local spinning drives, however.) A common example is use of consumer-grade NAS drives. As great as home NAS units are, throughput is always slower than local disk.
  • For local drives, the speed of the drive. Newer 'green' drives vary rotational speed to conserve power. Even 7200RPM disks can exhibit performance degredation compared to a 10k RPM drive.
  • For local drives, the degree of fragmentation. Even though the messages are small, they are placed into pre-allocated log files that may be highly fragmented.
  • Putting disk and log files on the same local volume. This causes head contention because a single message is written to both files before control returns to the application.
  • Linear versus circular logs. Linear are slower because the log formatter must allocate them new each time.
  • Whether syncpoint is used or not. If many messages are written in a single unit of work, WMQ can use cached writes and optimize the sector put operations. Only the COMMIT need ever be a blocking call.

Since non-persistent messages are handled entirely in memory, or overflowed to at most one disk file, then they are not affected by most of these issues.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • @Rob please help me her: https://stackoverflow.com/questions/48404838/load-balancing-issue-while-connecting-to-ibm-mq-using-jms-ccdt-file – atul tripathi Jan 23 '18 at 15:12
1

I believe your mirco-benchmarking is flawed (Using wrong benchmarking mechanism and you are also including i/o (System.out.println within the start and end time calculation) into the picture). Use a tool like Google's Caliper first to come up with correct the numbers and then seek for the answers. Last time I know (2003 i think), the MQ JMS implementation was a wrapper around Java MQI classes and we had to stick with Java MQI to meet our optimal throughput.

Community
  • 1
  • 1
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
  • 1
    FYI - The Java/JMS implementation has changed considerably since 2003. Both Java and JMS now inherit from the same base classes and WMQ now supports properties natively so much less mapping going on. – T.Rob Jul 04 '12 at 03:09
  • @T.Rob I agree and that is why I mentioned the year explicitly. But the measurement itself is flawed. – Aravind Yarram Jul 04 '12 at 03:10
  • I probably should have clarified I agree with the comments regarding the measurements. :-) – T.Rob Jul 04 '12 at 17:20
0

WebSphere MQ JMS messages carry additional headers (known as JMS headers) to support JMS style of messaging. JMSDestination, JMSReplyTo, JMSDeliveryMode, JMSType etc and provider specific JMS headers are part of the JMS headers. These headers are processed every time a message is sent or received.

On the other hand WebSphere MQ Java classes send/receive pure WMQ messages only. WMQ messages will have MQMD followed by message body.

So you can see the difference. The advantage of JMS message is that it is standards based and JMS messages are interoperable.

Shashi
  • 14,980
  • 2
  • 33
  • 52
  • 2
    I think the two performances should not be that different although JMS structure has more headers. Can it be mapping JMS message to WMQ message the one that causes the delay? – Lwin Htoo Ko Jul 03 '12 at 06:04
  • Agreed. While Shashi's point is legit, the difference seems extraordinary. – Nicholas Jul 03 '12 at 10:43
  • @Shashi, this answer suggests that the difference OP reports is legitimate when it is not. Headers do not account for two orders of magnitude difference in performance. – T.Rob Jul 04 '12 at 02:23
  • @LwinHtooKo No, the mapping of the messages could not cause a difference of two orders of magnitude. If I had to guess, it would be that you do not have a clean install of the WMQ client (i.e. you just grabbed the jars instead of running the installer) and the jar files are mismatched or you have a CLASSPATH problem. – T.Rob Jul 04 '12 at 02:29