9 Replies Latest reply on Mar 29, 2011 12:45 PM by ataylor

Performance of MessageProducer

nbhatia Mar 29, 2011 12:56 AM

I wrote a very simple command line program to test the performance of a JMS provider. Running it on HornetQ shows that the MessageProducer is lot slower than the MessageConsumer. The producer is sending messages at about 44 messages/second whereas the receiver can receive about 22,000 message/second! So I am trying to figure out what I can do to speed up the producer. Based on the Performance Tuning chapter in the user manual, this is what I have tried so far:

producer.setDisableMessageID(true): this made no difference
producer.setDisableMessageTimestamp(true): again, no difference
message.setJMSDeliveryMode(DeliveryMode.NON_PERSISTENT);: no significan difference
connection.createSession(true, Session.AUTO_ACKNOWLEDGE): setting transacted to true and then commiting after every 1000 messages causes a big jump in send speed (about 9,000 messages/second). However this doesn't look like a realistic scenario for my application which sends atmost one JMS message when it processes a service request. So I turned down the commits to one per JMS message and I am back to about 44 messages/second.

Am I missing something here? Are there any other tricks to speed up the producer?

P.S. My test was performed on a fairly fast Windows 7 machine with HornetQ running standalone. Both the producer and the consumer were running on the same machine as HornetQ, but connecting to it on port 1099 from a separate JVM. My source code for this test is available here.

1. Performance of MessageProducer

ataylor Mar 29, 2011 5:32 AM (in response to nbhatia)

message.setJMSDeliveryMode(DeliveryMode.NON_PERSISTENT) wont do anything, its used by messaging vendors when sending the nmessage not applications. set the delivery mode on the producer.
Actions
2. Performance of MessageProducer

nbhatia Mar 29, 2011 7:33 AM (in response to ataylor)
Thanks Andy. Setting DeliveryMode to NON_PERSISTENT on the producer immediately bumped up the send speed to 17,857 messages/second - what a difference! Furthermore, now if I disable messageIDs the speed goes even higher - 19,230 messages/second. However disabling message timestamp makes no difference. In any case, now I do understand some of the levers I can use to improve performance.

I do have a couple of followup question though.
In my application, setting DeliveryMode to NON-PERSISTENT is not an option - JMS is being used to transmit critical financial information that must not get lost. So are there any other levers I can use to improve the producer speed in PERSISTANT mode?
Why is the consumer speed so much higher in PERSISTANT mode (22,000 vs. 44) - does it not have to do the same kind of per message acknowledgements as the producer?
Actions
3. Performance of MessageProducer

ataylor Mar 29, 2011 9:36 AM (in response to nbhatia)

In my application, setting DeliveryMode to NON-PERSISTENT is not an option - JMS is being used to transmit critical financial information that must not get lost. So are there any other levers I can use to improve the producer speed in PERSISTANT mode?
Probably not, if your using persistant messages you are constrained by the speed of your disk, if you need faster throughput buy a faster disk.

Why is the consumer speed so much higher in PERSISTANT mode (22,000 vs. 44) - does it not have to do the same kind of per message acknowledgements as the producer?
Because the message is persisted on a send.
Actions
4. Performance of MessageProducer

nbhatia Mar 29, 2011 9:59 AM (in response to ataylor)
So if I understand this correctly, persistance is much more of a bottleneck compared to network communication (ack's etc).
Persistance of a message takes lot more time than its deletion (once the message receipt has been acknowledgd).
Actions
5. Performance of MessageProducer

ataylor Mar 29, 2011 10:19 AM (in response to nbhatia)

So if I understand this correctly, persistance is much more of a bottleneck compared to network communication (ack's etc).
Well that depends on how fast your disk and network is, but typically yes.

Persistance of a message takes lot more time than its deletion (once the message receipt has been acknowledgd).
We dont actually delete a message, we ack a reference as the same message can be sent to multiple consumers, but in simplistic terms yes.
Actions
6. Performance of MessageProducer

clebert.suconic Mar 29, 2011 10:19 AM (in response to nbhatia)

1. It really depends on the capacity of the hardware (disk / whatever_dispositive_to_store_data). the performance of a single producer will be really affected especially if you send synchronously.

The system is developed to use the maximum throughput available by the server, where we will batch many writes to multiple clients.

2. There's a lot more to be done on sending then ACKing a message.
1 of 1 people found this helpful
Actions
7. Performance of MessageProducer

nbhatia Mar 29, 2011 10:38 AM (in response to ataylor)

We dont actually delete a message, we ack a reference as the same message can be sent to multiple consumers, but in simplistic terms yes.

Does that mean that persistence storage keeps on increasing? When do you recover the space or is there a maintenance task to do this?
Actions
8. Performance of MessageProducer

nbhatia Mar 29, 2011 10:44 AM (in response to clebert.suconic)

Clebert Suconic wrote:

the performance of a single producer will be really affected especially if you send synchronously.

Aha, does that mean that I can increase the overall throughput by having multiple producers on multiple threads (possibly also using a seperate connection for each). I suspect though that on my machine disk will still be a bottleneck.
Actions
9. Performance of MessageProducer

ataylor Mar 29, 2011 12:45 PM (in response to nbhatia)

Does that mean that persistence storage keeps on increasing? When do you recover the space or is there a maintenance task to do this?
No, we discard/reuse journal files once there are no references in them

Aha, does that mean that I can increase the overall throughput by having multiple producers on multiple threads (possibly also using a seperate connection for each). I suspect though that on my machine disk will still be a bottleneck.
Yes. performance will scale up to a point, but remember at the end of the day, you will be constrained by network speed, disk speed, memory and processor power as always
1 of 1 people found this helpful
Actions

Go to original post