ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMIT queues to MQSI backing up

Post new topic  Reply to topic
 XMIT queues to MQSI backing up « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Mon Dec 03, 2001 10:54 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I am posting this under the MQSI section as I suspect that MQSI is invloved.

This test occured in our Hub and Spoke architecture, where QM1 was a spoke that was requesting, QMHUB is the hub with MQSI on it, and QM2 is a spoke that is replying. QM1 would send an 8000 byte request message in a standard copybook layout. MQSI would convert this to an XML Accord layout and put the request to QM2. QM2 would build the reply in the XML Accord format and send it to a second MQSI flow on the HUB. This second flow would then translate the XML back to the copybook layout, before putting the reply back to QM1. Messages were non persistent.

We wanted to stress the system, to see how much it could handle. As such, we needed to genereate a massive amount of messages in a short time. Even with all our test machines looping and producing requests as fast as possible, we never saw any of the queue depths rise above 1 or 2, which is good. But we wanted to push the system some more.

What I did was stop the channel from QM1 to the HUB. I had an application start putting request messages to the remote queue definition on QM1. (This remote queue definition resolves to a local queue on the hub that is an input queue to the MQSI message flow).As expected, the XMIT queue started to back up. Once it hit 2000 messages, I stopped the app. I started the channel. Messages started leaving the XMIT queue to the HUB at a rate of about 50-75 per second. The local input queue on the hub to the MQSI message flow never had a depth of greater than 0, meaning as soon as a message landed on the hub, the MQSI flow handled it.

At first we thought these were good results, our MQ setup with SI was handling 50-75 mps. But then I reran the same test. This time I had the 2000 messages sitting on the XMIT queue, with the channel stopped, but I also stopped the MQSI message flow on the hub. In other words, I expected the messages to pile up on the input queue to MQSI when I started the channel. I started the channel, and all 2000 message went across in 3 seconds!!! I reran this test several times both ways. Clearly our network was capable of sending almost 1000 of these message per second, yet when MQSI was involved, they were held back on the XMIT queue and only left QM1 at a rate of about 50-75 mps. If MQSI was a bottleneck in this test, shouldn't the messages back up on the local input queue to MQSI, not the remote XMIT queue?

Now, to add to the mix, I was also watching the XMIT queue from QM2 back to the HUB. While this test was running, and only 50-75 mps were leaving QM1, only about 1 reply message per second was coming back to the HUB. As the test ran, the XMIT queue on QM2 back to the hub eventually got up to something like 1900 reply messages, all stuck waiting! As soon as the requests all left QM1, and thus the fist MQSI flow ended, all 1900 made the jump from QM2, to the hub, thru the second MQSI flow, and back to the Reply2Q in under 5 seconds!!!

Apparantly there is something up with this first MQSI message flow that causes messages trying to come to the HUB that are destined to go to MQSI to back up on their XMIT queues. Both the first and second MQSI flow are in the same execution group, yet only the first one causes back ups. Also, please note that only message destined for MQSI input queues are affected. Other messages originating on other spokes have no problem during this test as they are routed thru the hub, only MQSI destined messages going to ANY MQSI flow while the FIRST MQSI flow is chugging along.


_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Dec 03, 2001 11:01 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

MQSI Version 2.01
HUB MQSeries 5.2 csd01 (NT)
QM1 MQSeries 5.1 csd01 (NT)
QM2 MQSeries 5.2 csd01 (Solaris 8.0)


_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMIT queues to MQSI backing up
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.