| Author |
Message
|
| elikatz |
 Posted: Wed May 12, 2010 7:44 am Post subject: Asynchronous MQ messaging |
 |
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
hi guys,
I got a question from our development, I'm copying his question as is:
Our scenario:
Java MQ client (located at site A) is sending messages to remote MQ server (located at site B) over WAN.
The sending behavior we observe is synchronous: until client is done sending one message and receives acknowledgement it cannot send another message.
How can we achieve asynchronous send?
How can we publish messages fast and receive acknowledgements asynchronously?
It's MQ 6.0.2.8 on windows 2003 server.
thanks,
Eli |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed May 12, 2010 7:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
V7 supports an "asynchronous" put.
Best bet to improve performance of the client is to stop using a client connection. establish a bindings connection to a local qmgr, let the qmgr talk over the WAN. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 7:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| WMQ v7 has a number of significant client performance improvements, especially for JMS clients. This requires MQ v7 at both ends though. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed May 12, 2010 7:57 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
MQ7 will get into development in the next few weeks but that's not good enough for now as need to get some answers for an existing client...
we would like to recommend the client to drop the client to server but we need some solid facts that server to server is better then client to server. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 8:00 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Bindings mode would allow the application to send messages to the local queue manager faster.
Whether QM sender channels are then faster than client channels is debatable, but I suppose the batchsize is the key issue here.
The effort/cost required to upgrade WMQ to V7 is likely to be less than any other alternative approach (IMHO). |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 12, 2010 8:17 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| elikatz wrote: |
| MQ7 will get into development in the next few weeks but that's not good enough for now as need to get some answers for an existing client... |
The first question was: "How can we achieve asynchronous send?"
The answer is: "This is available in MQ v7, not MQ v6."
See this link, for example: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaf.doc/cs13210_.htm
| Quote: |
| we would like to recommend the client to drop the client to server but we need some solid facts that server to server is better then client to server. |
Each MQI call from a client app involves time in the MQ client API library code (packing data for transfer), a network data transfer, and time in the MQ server's listener and/or SVRCONN MCA (unpacking transferred data). Compare this with the server-bound app where these costs are not present.
So IMHO it is a solid fact that server apps transfer their work to the queue manager quicker than client apps. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 12, 2010 8:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
More specifically, there are two network flows for each MQI call from a client-bindings app, namely: the MQI call sent to SVRCONN; the cc/rc returned to the client app.
For low-volume use, the client is ok.
_________________
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: Wed May 12, 2010 9:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mvic wrote: |
So IMHO it is a solid fact that server apps transfer their work to the queue manager quicker than client apps. |
No arguements there.
But, which is faster:
App A in client mode connects to QMA to put messages into LocalQueueA
-or-
App B in bindings mode connects to QM1 to put to remote queue Remote.To.LocalQueueA, and then QM1 sends to QMA.
The MQPUTs will surely complete faster in the second scenario, and if that's all you care about, we have a winner. But what if you care how fast the messages are available on LocalQueueA? Not so clear cut anymore..lot of variables in play that can swing the winner one way or the other.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 12, 2010 9:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| bruce2359 wrote: |
| For low-volume use, the client is ok. |
I have to disagree, IBMers at Hursley told me the improvements to WMQ v7 performance were specifically made to allow high performance for high volume clients. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 12, 2010 9:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I have to disagree, IBMers at Hursley told me the improvements to WMQ v7 performance were specifically made to allow high performance for high volume clients. |
IMS, max improvement in v7 clients is for non-persistent msgs, throughput increased up to 300%, says the presentations.
_________________
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 |
|
|
| elikatz |
| Posted: Wed May 12, 2010 10:39 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
does that imply to asynchronous put's or regular client to server setup?
BTW, thanks very to everyone up to here... it is very helpful and educating (i guess not only for me...) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 12, 2010 11:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
But, which is faster:
App A in client mode connects to QMA to put messages into LocalQueueA
-or-
App B in bindings mode connects to QM1 to put to remote queue Remote.To.LocalQueueA, and then QM1 sends to QMA.
The MQPUTs will surely complete faster in the second scenario, and if that's all you care about, we have a winner. |
This is specifically what elikatz's developer asked about. It's not about how long until the message is available, it's about how long until the client app can publish another one.
| PeterPotkay wrote: |
| But what if you care how fast the messages are available on LocalQueueA? Not so clear cut anymore..lot of variables in play that can swing the winner one way or the other. |
again, elikatz's developer is using pub/sub. The performance of the pub/sub delivery is presumably not in question. |
|
| Back to top |
|
|
| elikatz |
| Posted: Wed May 19, 2010 6:20 pm Post subject: |
|
|
Voyager
Joined: 24 Feb 2009
Posts: 86
|
a small update:
we have installed mq 7.0.1 on windows 2008 and it looks good - we did a very simple test with our application using the current mq libraries (version 6) and it looks good, no change needed.
when we try with the version 7 libraries the first thing we noticed is that they find the older versions loop-hole allowing java connect to connect with a space in as a user name.
now I got another query from my dearest developers, will mq 64 bit have advantages over the 32 bit version?
if so, looks like there is no win 64 bit version so we are back to the linux option... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Sat May 22, 2010 7:10 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Hi Elikatz!
In regards to your question about performance, 32-bit Windows vs 64-bit Windows on client connections is no performance advantage. 32-bit Windows vs. 64-bit Linux may see some performance improvement (3 percent at most).
From the limited information in your posts, it looks like you could use a good MQ Architectural review. I sense some significant performance achievements could be possible if you optimized the architecture.
Lance
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
