On z/OS, SYSTEM.CLUSTER.TRANSMIT.QUEUE is not the only queue that can be employed to handle cross-qmgr messaging load - though it's not part of MQ Clustering. From the z/OS Concepts and Planning Guide:
Intra-group queuing Intra-group queueing (IGQ) now supports large messages, the largest being 100 MB minus the length of the transmission queue header. You can perform fast message transfer between queue managers in a queue-sharing group without defining channels. This uses a system queue called the SYSTEM.QSG.TRANSMIT.QUEUE, which is a shared transmission queue. Each queue manager in the queue-sharing group starts a task called the intra-group queuing agent, which waits for messages to arrive on this queue that are destined for their queue manager. When such a message is detected, it is removed from the queue and placed on the correct destination queue. Standard name resolution rules are used but, if intra-group queuing is enabled and the target queue manager is within the queue-sharing group, the SYSTEM.QSG.TRANSMIT.QUEUE is used to transfer the message to the correct destination queue manager instead of using a transmission queue and channel. --- Hubert Kleinmanns <[EMAIL PROTECTED]> wrote: > Hi, > > in principle you are right, the information about > the Q locations, cluster QMgrs and channel > definitions are cached locally. So you will have > ONLY A LITTLE performance impact (which you mostly > will not see), because these informations are > refreshed sometimes. > > BUT, there are points, which may have a SIGNIFICANT > impact: All cluster sender channels read from ONE > XmitQ (the SYSTEM.CLUSTER.TRANSMIT.QUEUE). These > channels do not read one by one, but the read > messages with correlation ID (because the name of > the channel filled into the correlation id field). > On Unix you do not have an indexing on queues, so > reading may (and I think will be) slower, than > reading messages one by one. Additionally you > normally have more than one channel, which reads > from the SYSTEM.CLUSTER.TRANSMIT.QUEUE, and I guess > this will not increase the performance :-(. > > So it may make sense, NOT to use MQ clustering, when > you have performance issues (or you use faster > networks, disks or whatever). As I told in one of my > last mails: It depends on ;-). > > Regards > Hubert > > > > > -----Ursprüngliche Nachricht----- > > Von: MQSeries List > <[email protected]> > > Gesendet: 30.11.06 18:08:09 > > An: [email protected] > > Betreff: Re: multi-hop within a cluster > > > > does other people have/had performance issues with > mq clustering. > > > > my understanding of mq clustering is: > > > > IT is always a tradeoff between flexibility and > performance. mq clustering simplifies administration > because remote queues and channels are created > automatically. this costs something. > > > > but, this costs only arises the first time that > objects are created automatically. > > > > and, repository look-ups are kept in cache. > > > > that's how mq tries to minimize the performance > loss. > > > > please correct me or improve my statements. > > > > > > > > > > > > -------- Original-Nachricht -------- > > Datum: Tue, 28 Nov 2006 14:52:01 -0800 > > Von: Christopher Warneke > <[EMAIL PROTECTED]> > > An: [email protected] > > Betreff: Re: multi-hop within a cluster > > > > > Reasons why I disagree: > > > > > > 1. For all of the simplification that > clustering > > > brings, there is a loss of performance. We see > times > > > of .004 seconds for unclustered (sdr/rcvr pair) > > > message transmission avg. verses .014 seconds > for > > > cluster message transmission avg. In this shop, > 10ms > > > here, 10ms there, means not having transactions > > > complete in less than a second. We need > subsecond > > > response times. > > > > > > 2. It's a lot easier to change 1 routing rule > in a > > > control table, than to change n number of mq > object > > > definitions. Sure, in some little test > environment > > > you can go and change things as you want - on a > > > production system, the change mangement work to > > > redefine the mq environment will make you wish > you > > > only had to change 1 routing rule. > > > > > > 3. QSGs and Shared Channel solutions are better > than > > > clustering - if you have z/OS. If not, maybe > > > performance is not such an issue and you can > cluster > > > the thing to death. Most of the MQ performance > issues > > > that we see, result from designs that work. > Messages > > > get where they are supposed to go. Just not > that > > > efficiently - and then things begin to fail > under > > > heavy load. > > > > > > 4. What exactly does "breaking a fly on the > wheel" > > > mean? Do you mean that it is overkill? There is > a > > > point in scale where brokering is the easiest > > > approach, and your clustering solution becomes > the fly > > > in vaseline. Think about support for this, as > if you > > > were not the person supporting it. Maybe the > 'next > > > guy' wants to do it the easy way, and have the > > > application people be responsible for routing > changes. > > > > > > > > > So there... > > > > > > > > > --- Hubert Kleinmanns <[EMAIL PROTECTED]> > wrote: > > > > > > > I think, using a message broker to route > messages is > > > > like breaking a fly on the wheel ... > > > > > > > > MQ clustering is designed for simplifying > > > > administration tasks. Now you need not to > define any > > > > channel definitions or remote Q definitions > > > > manually. The cluster algorithm propagates the > > > > neccessary definitions to the cluster members, > but > > > > the Qs and channels are going the direct way. > > > > > > > > But, you could define alias queues on a > gateway > > > > system, which point on local queues on the > target > > > > systems. In this case alias queues and local > queues > > > > must have different names. I did not test it, > but > > > > this should work. > > > > > > > > I would NOT use the mechanism I described > above, > > > > because it is contrary to the cluster > concepts. > > > > Instead I would use overlapping clusters as > follows: > > > > > > > > 1. Put the sending QMgrs and the gateway QMgrs > into > > > > one cluster (e. G. CL1). > > > > > > > > 2. Put the receiving QMgrs and the gateway > QMgrs > > > > into a second cluster (e. G. CL2). > > > > > > > > 3. Define alias Qs on the gateway QMgrs in > CL1, > > > > which point to local Qs in cluster CL2. > > > > > > > > 4. On the sending QMgrs put the messages to > the > > > > alias Qs in cluster CL1 on the gateway QMgrs. > > > > > > > > 5. The gateway QMgrs now resolve to the local > Qs in > > > > cluster CL2. > > > > > > > > 6. The sending QMgrs do not see the local Qs > in > > > > cluster CL2, so the names of the alias Qs on > the > > > > gateways and the local Qs on the receiving > QMgrs may > > > > have the same name. > > > > > > > > I tested point 6 and it worked, but maybe when > you > > > > have to gateways, they could route the > messages to > > > > the other gateway (and back). In WebSphere MQ > > > > version 6 this may be prevented by using the > > > > CLWLRANK attribute. > === message truncated === To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
