| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Client to Qmr vs Qmr to Qmr set-up |
« View previous topic :: View next topic » |
| Author |
Message
|
| ncritx99 |
 Posted: Mon Nov 07, 2005 10:29 am Post subject: MQ Client to Qmr vs Qmr to Qmr set-up |
 |
|
Newbie
Joined: 04 Nov 2005
Posts: 1
|
Hello folks,
We are planning an MQ client to remote Qmgr deployment expecting an exchange average of 33K datagrams per day with a potential peak period of 7200 datagrams (in an hour). The Websphere MQ version would be either v5.3 or v6.0 running on servers using MS Server 2003.
Based on support packs provided by IBM (MP78 & MP7H), it appears that a client deployment has the ability to handle the workload we plan on throwing at it.
The one issue we need guidance on is related to the robustness of the client deployment. Using a serverconn channel for the bi-directional exchange of messages and the "lower" standard of message control (as opposed to batches, UOW tracking and sequence no monitoring on regular Qmgr to Qmgr send/receive channels) is worrisome.
It would appear that a Qmgr to Qmgr set-up offers more flexibility and greater recovery options from channel failures then a client to remote Qmgr.
Any advice which could help dispel these concerns would be appreciated.
Cheers,
NCRITX99
 |
|
| Back to top |
|
 |
| hopsala |
| Posted: Mon Nov 07, 2005 12:10 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Since you did not state what your datagram size is, it is quite difficult to asses your total throughput - number of msgs is, naturally, insufficient...
This question is much discussed around the forum, so in short:
- Clients are slower, much much slower, and there is no real way to pre-check if it can take the workload other than benchmark testing. If it can handle it, fine, if not, consider a QM.
- Clients work synchronously with the QM they connect to, which means that if the network fails your program gets stuck, and has to either go down or start accumulating unsent msgs. In effect, you lose almost all the benefits WMQ gives you.
A QM-QM conn, however, if the QM is up (and believe me, it's a very stable product - it is always up) programs don't have to worry about machines going down, network problems or anything to a certain limit, which is rarely touched.
- Clients are not considered "assured delivery" - though in effect, I have personally never lost a message due to a client channel error though I have used them in many a production system in the past. IBM states "we do not assure no data is lost" real life states "clients do not lose data" - it's up to you to weigh your options.
- QMs cost money, Clients do not. QMs cost additional funds through maintainance, approx one MQ administrator per 20 QMs (this is a very crude estimate, served to give you a general idea).
- If there's a DB involved - for example, an appl that selects from a table, sends msg to MQ and deletes the row - you must use some XA coordinator. This cannot be done with a normal client, but only with something called "WMQ Extended Transactional client'; since this extention costs about as much as a QM license (or at least that's what someone once said here), it's probably preferable to simply use a QM.
- QMs are easier to maintain, monitor, configure, etc etc etc.
Bottom line - if you have the money, time and people to maintain the necessary number of QMs, use a QM-QM connection. If you don't, use a client.
Last edited by hopsala on Tue Nov 08, 2005 11:28 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 07, 2005 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Just my thoughts hopsala, very well put  |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Nov 07, 2005 5:15 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Clients have a 4MB msg limit. |
????
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 07, 2005 7:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
| Clients are slower, much much slower, and there is no real way to pre-check if it can take the workload other than benchmark testing. If it can handle it, fine, if not, consider a QM. |
But be sure to compare apples to apples.
If a local MQPUT to a remote q definition takes 0.01 seconds, whereas a MQPUT to a local queue on a remote QM that you are connected to takes .1 seconds, that does not mean the MQClient was 10 times slower! Don't forget to factor in the time it takes QMA to move the message to the XMITQ, for the SNDR channel to move the message to the other QM, for the other QM to accept it, and finally for the channel to complete the batch. This all takes time and must be considered to make a fair comparison.
Other than my mainframe apps, I would say 99% of my apps are MQClients, and working fine for years. You just have to code for it (i.e. syncpoint, etc).
And remember, if the app truly needs to be 1000% bullet proof, you got the exact same worries for a local app as you do for a MQClient. A local app can lose its connection to the QM just as a client can, but obviously it is much much rarer (but not 1000% rarer!).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Nov 08, 2005 11:28 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| wschutz wrote: |
| Quote: |
| Clients have a 4MB msg limit. |
???? |
Woops! How did that get in there? 
This is obviously not true, and was accidently pasted from another post I was writing at the same time. For using MQSERVER it is indeed 4MB, but channel tables are limited by normal WMQ limits.
Re-Edited, Corrected, Re-Examined and Certified. Forgiveness obliged. |
|
| 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
|
|
|
|
