| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Performance problem using Get |
« View previous topic :: View next topic » |
| Author |
Message
|
| gbaddeley |
 Posted: Wed Mar 16, 2011 10:06 pm Post subject: |
 |
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
I won't hurt to open a Service Request with IBM...
_________________
Glenn |
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Thu Mar 17, 2011 6:47 pm Post subject: Re: Performance problem using Get |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Which connection option does the code use to connect to the queue manager? An MQ client connection can perform significantly slower than an MQ server connection; this is probably more true for older versions of WebSphere MQ.
| palaslet wrote: |
1. This code fetches 200 messages in 10 seconds.
| Code: |
using (MQQueue mqQueue = mqQMgr.AccessQueue(connectionParameters.QueueName, MQC.MQOO_INPUT_SHARED + MQC.MQOO_FAIL_IF_QUIESCING))
{
List<WebSphereMQMessage> uncommittedMessages = new List<WebSphereMQMessage>();
Boolean hasMoreMessages = true;
Console.WriteLine(DateTime.Now.ToString("hh:MM:ss.fffff") + " start fetcing");
while (hasMoreMessages)
{
MQGetMessageOptions mqGetMsgOpts = new MQGetMessageOptions();
mqGetMsgOpts.Options |= MQC.MQGMO_NO_WAIT;
mqGetMsgOpts.Options |= MQC.MQGMO_NO_SYNCPOINT; |
|
Moving the AccessQueue() call outside the loop was a good idea; it wouldn't hurt to move the GMO options outside the loop as well, or to add the MQC.MQGMO_FAIL_IF_QUIESCING option.
Does that get all 200 messages? If it's pulling messages off faster than the sender puts them on, the while loop could end prematurely, due to MQC.MQGMO_NO_WAIT.
| palaslet wrote: |
2. If I uncomment the part handling the messages, the performance drops to 200 messages in ca 14 minutes 40 seconds
The "newMessageReceivedCallback" method will do a 20 ms sleep to simulate validation and paring into database. It shouldn't add more than 4 seconds to the total time
| Code: |
//if (uncommittedMessages.Count > 0)
//{
// foreach (WebSphereMQMessage mqMsg in uncommittedMessages)
// {
// if (newMessageReceivedCallback == null || newMessageReceivedCallback(mqMsg))
// messages.Add(mqMsg);
// }
// uncommittedMessages.Clear();
//} |
|
There's definitely something else going on then, not necessarily related to MQ. It might be worthwhile to set up some sort of profiling when running the code. |
|
| Back to top |
|
|
| palaslet |
| Posted: Thu Mar 17, 2011 11:49 pm Post subject: |
|
|
Newbie
Joined: 15 Mar 2011
Posts: 9
|
Hi all,
I've solved the problem. 
Turns out (of course) that the problem was in my coding. The environment i tested from was a highly dynamic multi threaded environment, and one of the threads was holding the queue manager busy much of the time.
When I removed the code that held up the QM it all worked fine. No delay at all from MQ.
Thanks again for engaging in this. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
