| Author |
Message
|
| PeterPotkay |
 Posted: Wed Sep 11, 2002 12:11 pm Post subject: Can Clustering slow you down? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QM1 on Server1 has a local QueueA.
QM2 on Server2 has remote queue def called QueueA, pointing to QueueA on QM1. It also has a local reply queue called ReplyB
App connects to QM2 and drops request messages to remote QueueA, asking that its replies come back to ReplyB. Life is good and the roundtrip takes X milliseconds on average.
Now QM1.1 comes up on Server1.1. It also has a local queue called QueueA.
QM1, QM1.1 and QM2 all get clustered, and the remote def of QueueA is removed from QM2.
If the same app connects to QM2 to put requests to QueueA, round robining will take place.
Will the total round trip time for a single message be faster , slower or the same? Does the workload algorithm add time to the transaction?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| jc_squire |
| Posted: Wed Sep 11, 2002 1:55 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
Hi Peter,
Have not tested this but I think the total round trip for a single message could be faster.
Assumed you are implementing a second server to reduce the time delay in generating a reply message so although the workload exit might delay the transmission of the request message by a few hundredths of a second it does not matter because the request message will probably spend less time on the queue waiting to be processed as there are 2 servers processing request messages and generating replies.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Sep 11, 2002 3:18 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Hmm... Good question. Round-trip time for a single message may be slightly longer in a clustered environment - but I think that this is the trivial case. When you are talking about thousands of messages per second in a large scale system, many other factors come into play, and that's when clustering shines...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nimconsult |
| Posted: Wed Sep 11, 2002 10:09 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
If you talk about one message, I would say that you will notice no significant difference. There is just a very small overhead of the round-robin algorithm (assuming you open with bind not fixed).
To go further on the comment of Brandon, I would say that clustering "shines" mainly in term of administration when your infrastructure (number of queue managers) grows.
I would not say that the cluster in itself shines in term of performance when the message throughput increases. The increase of performance comes essentially from the scalability of the application. For the performance of message transmission, I would say that a cluster is less efficient than a fully wired network of queue managers (administration nightmare) because the cluster uses a single transmission queue for all the queue managers. Thus contention on this single transmission queue (consider the overhead of having a single message for QM2 lost in thousand messages for QM1)
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Sep 12, 2002 12:17 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Nicolas,
Thanks for adding the more detailed comments. I was thinking much of the same, but Peter's question caught me on the tail end of just having finished 12 hours of coding, and my fingers were too lazy to type it all out. But I'm in full agreement with you. The roundtrip time will never be faster for clustering; you always have the overhead of round-robin. But scalability and administration is what we're after with clustering; and in a way, this indirectly increases performance - of us guys running everything at least 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 12, 2002 4:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Thanks guys; thats what I thought. This is for a project where the message leaves the mainframe, goes to a hub for MQSI transformation and then goes to a distributed platform for rules execution, before returning back to MQSI for the reverse transformation and finally back to the mainframe.
In 1 environment the distributed platform was a single machine and we were getting 99.9% of our replies back with a 1500 ms wait time.
In the second environment, the only diff was that the distributed side was now clustered. Only 90% of the messages were coming back in time. I upped the wait to 2000 ms and have had no problems since. I wonder if the clustering is the cause of the slow down. (Then again maybe 1550 ms would be enough. I picked 2000 for ha-has. We will look to ease it back to as small a # as possible)
We will be doing all sorts of perfomance eval over the next few weeks to see where our time is being spent for the roundtrip.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Sep 12, 2002 11:13 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Another possible slowdown is that all messages bound for clustered queues pile up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE rather than dedicated XMIT queues for each channel. I'm not sure what algorithm governs the threading of MCAs etc, but this factor could account for some of that ~500ms increase...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
