| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Performance: Websphere MQ client versus local server? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jclane |
 Posted: Mon Jun 13, 2005 9:33 am Post subject: Performance: Websphere MQ client versus local server? |
 |
|
Newbie
Joined: 13 Jun 2005
Posts: 2
|
I have a setup of Websphere MQ where Websphere application server is communicating to MQ through a MQ client (to a remote MQ server on the same subnet over Gigabit Ethernet) instead of a local server connection (on the same box) and when the volume gets heavy the queues start to fill up and everything slows down.
Based on my knowledge of MQ we should be able to enhance performance by putting the MQ server and Websphere both on the same physical machine (the hardware can handle both fine) and having Websphere talk through a local server connection instead of the client.
I'm basing this information on something an IBM MQ expert once told me about the client. He said that the client has to block while reading/writing from the queue, but the server does not have this restriction.
I'm looking for any recommendations anyone can give me about the differences in performance between the MQ client and MQ server connections. and any possible resources (URLs, pdf, etc) outlining the differences.
Sorry if this has been discussed before but I couldn't find anything specifically relavent using a search. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Jun 13, 2005 2:27 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Consider an MQPUT call for an MQClient. You issue the MQPUT, and the call "blocks" until the data fgoes over the network, is handled by the surrogate on the QM side, and then the results of the MQPUT come back. Only then does the MQPUT end.
Samething for an MQPUT in bindings mode. You issue the MQPUT, and it blocks until the result of that call is known.
Both "block", but obviously the local call will be much faster.
Take it a step further, and run the local app as a FASTPATH, or trusted, app. Now you bypass the LQM Agent on the QM, and run directly with the QM. Even fatser. But look out if your app crashes, because so will your QM.
You are not going to find comparisons on this, because so much depends. Speed of network, client server, MQ server, message size, etc.
Also, if your messages are persistent and do not need to be, change them to be non persistent. That will speed things up, whether you are a client or local.
And finally, be 100% sure MQ is the bottleneck. You may go to all this effort, only to discover that a DB call is the pig and you are still slow.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jclane |
| Posted: Tue Jun 14, 2005 4:30 am Post subject: |
|
|
Newbie
Joined: 13 Jun 2005
Posts: 2
|
Thanks a lot. That's kind of the same logic I was following.
The people in charge of the application (I'm not one of them, I was brought in to look at the 'slow' response times) swear that the access to the database is not the problem. I don't know that I'm sure of that, but they wanted me to look at the Java to MQ link first. |
|
| 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
|
|
|
|
