| Author |
Message
|
| anveshita |
 Posted: Fri Jun 17, 2011 12:07 pm Post subject: MQ Server dilemma |
 |
|
Master
Joined: 27 Sep 2004
Posts: 254
Location: Jambudweepam
|
Hello:
We are looking at a vendor product for one of our business requirements. The product need to be installed on multiple WIN servers and needs MQ Server software installed in all. The MQ licenses would be becoming costly as the WIN server need to be bit at higher processing power. So I am checking out the possibility of installing the MQ Server on one of the WIN servers and letting the rest of the servers make client connections. Assuming that the vendor software allows client connections to be made, what could be the down side of NOT having MQ Server software on each WIN server. To be precise, what would be the problems one would expect changing connection to local queue manager with a client connection to a remote queue manager.
Any practical experiences/lessons learnt? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Jun 17, 2011 12:17 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
There have been in depth discussions on mqseries.net discussing clients versus QM to QM connections, and the pros and cons of each at a high level.
That will give you an idea at a general level.
At a more specific level, there are not enough details in your question to make a call one way or the other.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| anveshita |
| Posted: Fri Jun 17, 2011 12:35 pm Post subject: |
|
|
Master
Joined: 27 Sep 2004
Posts: 254
Location: Jambudweepam
|
| Thanks. Reviewing again. I have not seen anyone posting the practical experiences. But no harm in reading again |
|
| Back to top |
|
|
| camauz |
| Posted: Wed Jun 22, 2011 11:27 pm Post subject: Re: MQ Server dilemma |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
| anveshita wrote: |
To be precise, what would be the problems one would expect changing connection to local queue manager with a client connection to a remote queue manager.
|
Here are some opinions related to functional aspects (I don't afford the performance aspects because those are completely different stuff).
1. If you are connecting to the queue manager from WebSphere Application Server and you are using JMS container managed sessions, you will not notice any difference between a local or a remote queue manager.
2. If you were connecting to the q.m. from a different JEE container, you should verify if "Distributed Transaction Processing" (XA) is supported. If it wasn't, you wouldn't get "two phase commit".
3. If you are using a different stack (C, COBOL, standalone JVM Java, etc...), you will need a local queue manager to achieve "two phase commit" (refer to MQBEGIN/MQCMIT/MQBACK). There is an additional product named ETC (Extended Transactional Client): it might help you achieving "two phase commit" when using Tuxedo, TXSeries and so on without a local queue manager, but unfortunately it's licensed as a server.
4. I have no idea about C# and Microsoft stuff.
From a functional point of view, I don't know other limitations execept the DTP one.
Regards,
Ch. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 22, 2011 11:44 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If the app can use a client connection, and are just moving the QM to another host - the main concern is that the QM may be taken down (or fail over if HA/MI) while the client app is still running.
So the client app should respond appropriately to a MQRC 2009, or a MQRC 2059 condition and ideally attempt re-connection without manual intervention (every say 30 secs).
Similarly the client app may be started when the QM is down and the same considerations apply. It's easy enough to test these scenarios. Ideally the client should use a CCDT. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 23, 2011 4:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MQ server-bindings apps make cross-memory (RAM) calls to the qmgr. MQ client-bindings apps make cross-network calls to the qmgr, even if the client app is in the same o/s or in a different o/s in the same computer room.
Network flows are always slower than cross-memory flows. So, throughput will be lower on client apps, much slower for large messages in heavy workloads.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Jun 23, 2011 4:46 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| MQ client-bindings apps make cross-network calls to the qmgr, even if the client app is in the same o/s |
No physical network transfers are involved for 127.0.0.1. The performance compared to MQ's shared memory capability is lower, but I'd guess that that is an issue of the sockets code having to use more generic memory buffer management and increased crossing from user to kernel mode, compared to the non-socket code. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 23, 2011 5:20 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| With modern LANs, there would have to be a tremendous amount of data to really worry about client connections affecting performance. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 23, 2011 5:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| With modern LANs, there would have to be a tremendous amount of data to really worry about client connections affecting performance. |
While I generally agree with this statement, clients are slower; and clients are a more prone to network-inflicted problems. These (potential) issues must be weighed against the cost of additional server licenses.
One of my clients (company) had a batch mq client app that transferred a few million messages to a qmgr in another state; and they were just about to exceed their batch window. A qmgr-qmgr channel connection dramatically reduced the clock time for this app.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 23, 2011 6:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Or a large number of messages. Many people don't want to send millions of messages.
We send relatively few per day, but they are high value.
IBM have also improved client performance significantly in version 7. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 23, 2011 7:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| IBM have also improved client performance significantly in version 7. |
Yes, things client-ish are much improved at v7. But...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 23, 2011 3:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| zpat wrote: |
| With modern LANs, there would have to be a tremendous amount of data to really worry about client connections affecting performance. |
While I generally agree with this statement, clients are slower; and clients are a more prone to network-inflicted problems. These (potential) issues must be weighed against the cost of additional server licenses.
One of my clients (company) had a batch mq client app that transferred a few million messages to a qmgr in another state; and they were just about to exceed their batch window. A qmgr-qmgr channel connection dramatically reduced the clock time for this app. |
Did this reduced clock time for the app include the time it took the messages to get from the local QM over to the remote QM in the other state? Or was the only concern how long it took the local app to finish putting to the local QM, and the extra time to move the messages over to the other QM was not counted?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 23, 2011 5:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I believe I understand your question, Jeff.
The transfer of all messages must be completed before the next batch job can begin its process. The message count must match exactly at both ends.
So, process time at both ends, plus network transfer time, was longer with client-bindings than with server-bindings qmgr-qmgr channels.
All this was and v6-something.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 23, 2011 8:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| I believe I understand your question, Jeff. |
Jeff? Did you have an off thread conversation with him? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 24, 2011 3:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Ooooops, it was Mr. Potkay that asked me about throughput, clock-time, etc..
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
