ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WS with WBIMB Performance

Post new topic  Reply to topic
 WS with WBIMB Performance « View previous topic :: View next topic » 
Author Message
hornbeam123
PostPosted: Fri Dec 21, 2007 10:05 am    Post subject: WS with WBIMB Performance Reply with quote

Centurion

Joined: 01 Nov 2003
Posts: 101

We have some flows acting as a WS facade others will call 'external' WebServices. They need to be designed and implemented for high throughput.

I'm looking for any performance hints and tips. I have studied the performance supportpaks but not found anything specific to WS with WBIMB. I did find some useful information about the workings of the HTTP Listener in the text of APAR IY66263.

From testing I see the messages put to the SYSTEM.BROKER.WS.INPUT and REPLY queues are non-persistent.

Let's say we have a pair of flows acting as a ws facade, one dealing with http inputs and mqoutput request and the other with mqinput reply/http replies.

Would it be performant to duplex the no. of instances of the flow as well as replicate the flow across many execution groups? Indeed does the additional instances property of the message flow apply to HTTP Input
nodes bearing in mind the brokers use of its internal WS queues ?

We have a pair of broker hosts sharing the workload with low utilisation and with two processors.

I think I know what the forum might say but this discussion would be useful for other users nonetheless.

Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri Dec 21, 2007 10:11 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

It should reasonably follow from the fact that the nodes internally use queues, that the scalability and performance characteristics of using additional instances and additional EGs are comparable for flows that start with MQInput nodes.

With the caveat that you may need to implement IE01.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Dec 21, 2007 4:20 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

IMHO, and this is in no way an official one, you would be better served for performance with SOAP over JMS instead of SOAP over http....
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hornbeam123
PostPosted: Mon Dec 24, 2007 3:14 am    Post subject: WS with WBIMB Performance Reply with quote

Centurion

Joined: 01 Nov 2003
Posts: 101

Thanks for your advice.
Back to top
View user's profile Send private message
mqmatt
PostPosted: Mon Dec 24, 2007 7:27 am    Post subject: Reply with quote

Grand Master

Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK

You may also want to investigate the SOAP nodes in v6.1, as these work completely differently to the HTTP nodes (they don't use queues for a start, and requests to external web services can be made asynchronously).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WS with WBIMB Performance
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.