| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Anyone use IA91? |
« View previous topic :: View next topic » |
| Author |
Message
|
| duffMan |
 Posted: Sun Oct 26, 2003 7:15 am Post subject: Anyone use IA91? |
 |
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
I am trying to solve the age old problem of relating a reply message back to it's request.
I have investigated a few options and am trying to select the best method, both for performance and stability. [Read: support pacs are not supported thus better work darn well or management will have me for dinner]
Option1: DATABASE
- this seems very expensive because the actual insert will cause the DBMS to log and write the insert to disk. The retrieval however is fast.
Should be stable and is supported. (but you've got to get rid of old record).
Option2: Support PAC IA09 MQGet
- this seems to be better than the DATABASE option however, a disk i/o cannot be avoided (logging can though) and is not supported.
Option3: Support PAC IA0H - PostIT
- ?????
Option4: Support PAC IA91 - Cache
- this appears that it may be the fasted method, however it is unsupported.
Anyone have any experience with Option 4? If it is stable then this may be the way to go since performance is VERY critical in this app.
Does V5 have any options (besides 1) built in?
Also, I'm on V2.1 CSD4 and am thinking of moving to V5. What are the chances of options 2,3,4 not working in V5? |
|
| Back to top |
|
 |
| fitzcaraldo |
| Posted: Sun Oct 26, 2003 5:46 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003
Posts: 98
|
Re the MQGet node IA09. It's worth noting that the supplied code cannot be rebuilt as is. Some of the APIs changed between 2.0 and 2.1. Not a major deal but worth doing if you are taking it forward and you have to support it.
Do the POSTIT and Cache options let you store the request message persistently and transactionally? Does it matter if you lose the stored request message if the broker goes pear shaped while you are waiting for the reply? If so, the only real option is the MQGet or database. |
|
| Back to top |
|
|
| duffMan |
| Posted: Sun Oct 26, 2003 8:21 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
I do not need to store any messages persistently in this interface. Nor do I need transaction control.
What I do need is top notch performance, and if I had to choose between the later two you mentioned, MQGet would be the choice because you can easily control if the MQPuts are logged or not and I wouldn't have to explitely clean up the mess.
I would assume the request to range anywhere from 6K to 60K but would not rule out very very odd-ball case of 600K. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 27, 2003 5:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| duffMan wrote: |
| What I do need is top notch performance |
What counts as 'top notch performance'? 5 nanosecond throughput? 5 second flow throughput? 50 second flow throughput?
How are you measuring performance? How have you defined your performance needs - i.e. how do you know what performance specs have to be met?
Without good ideas of the answers to these questions, you can't really say you're picking a method based on 'it gives top notch performance'. You can say "this one takes less cycles than the others", but that may be meaningless compared to the performance characteristics of the rest of your flow.
There are also a few other options you haven't looked at (or at least haven't mentioned). - Aggregate nodes - there's nothing wrong with using these to aggregate only one response to one reply.
- Writing a custom plug-in that does what you want yourself - possibly based on the Cache plugin or etc.
- Thinking outside the WMQI box - and using a C application to correlate your replies and augment the data before it goes back to
WMQI.
From a performance perspective, the aggregate nodes are going to be fairly slow - as they do database calls "behind the scenes". But they're supported and included in both 2.1 and in 5, and may be fast enough for your needs.
The performance of the other two options is exceedingly variable. But they're worth at least thinking about.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| duffMan |
| Posted: Mon Oct 27, 2003 5:00 pm Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
As a matter of fact I do know my performance requirements. [one of which is 0.5s round trip..but that likely means little to you]. And obviously 50s thoughput is not top notch smart azz, but thanks for that.
What I am looking for is a solution which consumes "less cycles" if you like, yet is a very stable and maintainable solution to correlate a reply message with a request. There are probably 6 other methods that you didn't mention but I don't have time to investigate all....hence the query on this forum.
The Cache node looks to fit the bill but I particularily don't want to waste my time with it if is not stable...but I guess I'll have to find out the hard way. Yipeee! |
|
| 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
|
|
|
|
