| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JMS QueueReciever - Performance Question |
« View previous topic :: View next topic » |
| Author |
Message
|
| sieijish |
 Posted: Fri May 19, 2006 4:01 am Post subject: JMS QueueReciever - Performance Question |
 |
|
Acolyte
Joined: 29 Nov 2004
Posts: 67
Location: London
|
I am using JMS API to connect to a Queue and receive messages from the queue. Each message is around 1KB and is persistant.
A single instance of QueueReceiver doing a commit per message is able to consume message at around 120msgs/sec.. I was able to run 5 instances of QueueReceivers and the combined message rate crossed 600msg/sec.
At this time when I checked the disk usage on the MQ Server (Aix), i could see that only the disk-1 storing the MQ Log files are in use & disk-2 storing the MQ Q file is not at all used. These are internal disks.
Now, when I change the QueueReceiver program to do MQ Commit after receiving 30 messages, then the throughput decreased and the disks storing the MQ Q file became very busy.
I was expecting to get some benefits by introducing the batch commit. Any thoughts into what is the best way to do this?
The reason why I want to do batch commit is because in my QueueReceiver program, i take the message & insert it to Oracle. If i do commit per message than I do a db commit per insert and it is very inefficient on DB side and I have to do batch commit.
I was expecting MQ to be more efficient with Batch commits.
Regards,
SD |
|
| Back to top |
|
 |
| RichCumbers |
| Posted: Mon May 22, 2006 4:19 am Post subject: JMS QueueReciever - Performance Question |
|
|
Novice
Joined: 22 May 2006
Posts: 10
Location: Hursley, UK
|
Hi
What version of MQ/JMS are you using?
Firstly may I point you to the following link:
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24009979&loc=en_US&cs=utf-8&lang=en
This is a performance report for WMQ on AIX machines, if you have not read it, then it might be worth looking over (If have already seen this I apologise).
Maybe you could try improving the performance of the Queue Manager by adding the following when creating the Queue Manager:
crtmqm -q -u SYSTEM.DEAD.LETTER.QUEUE -h 5000 -lc -lf 16384 -lp 16
Where -lf defines the size a log can be, and -lp defines the number of primary log files the system can have. -lc defines circular logging.
Let me know if this improves performance
Rich |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
