| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ in "REAL TIME" |
« View previous topic :: View next topic » |
| Author |
Message
|
| gomiecinski |
 Posted: Mon Feb 14, 2005 7:09 am Post subject: MQ in "REAL TIME" |
 |
|
Newbie
Joined: 13 Jan 2005
Posts: 2
|
| I am looking for opinions from anyone who has installed MQ to be used as a real time product in a "request/response" application. By "REAL TIME" I am expecting the average response time to be sub-second. I am interested to know if MQ can support transaction volumes between 15-30 TPS. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Feb 14, 2005 7:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It depends on your configuration.
If you're using smallish non-persistent messages on a single server, then you should be able to get hundreds or thousands of TPS.
If you're using 60 meg messages that need to go through multiple hops across slow networks and through several transformation steps...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 14, 2005 12:35 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Non-persistent, messages, over multiple MQ client channels for example, will add very little overhead on top of the basic network latency.
Certainly sub-second, even under high load, is achievable with one queue manager where the application either runs on the same system or each requestor connects to the QM with their own client channel.
You may to consider your threading and connection design for optimum throughput and low latency. But the same is true for any connection method.
IBM publish performance papers as support pacs. 30 TPS is nothing on a modern system. But do make sure the messages are non-persistent. |
|
| Back to top |
|
|
| kman |
| Posted: Mon Feb 14, 2005 9:38 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
why is this fascination with REAL TIME?
Is it because the message or transaction is no longer useful after a certain duration? If that's the case, then ensuring it is a non persistent message make full sense.
Even if you make it persistent, would the message be any more valuable after its life span? Persistent message is good for recovery purposes. For this, events after recovery is no longer REAL TIME. Making the message persistent is asking for the queue manager to eventually write the message to log, which adds to the system overhead.
Just curious. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 15, 2005 2:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
MQ is asynchronous.
There is no real time but only near real time.
You cannot do a two phase commit with 2 qmgrs: if you put your message on qmgr1 and it is processed by qmgr2. The message will not travel to qmgr2 until it has been committed....
Enjoy  |
|
| 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
|
|
|
|
