| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| performance - pub/sub model |
« View previous topic :: View next topic » |
| Author |
Message
|
| tborrome |
 Posted: Wed Apr 10, 2002 11:49 am Post subject: |
 |
|
Novice
Joined: 03 Apr 2002
Posts: 17
|
just reposting my query ...
Hi, I'm setting up MQseries to run with 10 topic publishers on 1 machine continuously sending messages to 100 subscripers in another machine ... The performance I'm seeing is terrible - particularly on the subscriber side. After the 10 publishers continuosly send messages for 5 minutes, the subscribers will take forever to consume all those messages. Monitoring it from the back end ... seems that SYSTEM.BROKER.DEFAULT.STREAM queue just continously grows and a lot of other systems queues starting with SYSTEM.JMS.ND.3CADD ... get created dynamically and queue up messages. There were around 1000 of those queues created.
Given the the pub-sub architecture of MQ seems to be going through layers of internal system queues, do you know how I can improve the performance of this? Any performance tuning tips and information will be great.
Does anyone know how to clean up this dynamically generated system queues created by the Broker (SYSTEM.JMS.ND.3CADD ...) ?
Thanks and regards,
Tyrone
|
|
| Back to top |
|
 |
| StefanSievert |
| Posted: Wed Apr 10, 2002 12:24 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Tyrone,
the first question would be what version of MQ are you running on which platform using what version of MA88?
You have a choice in JMS wether you want to share one queue across multiple subscribers or have a dynamicq created for each subscriber. Dynamic queue creation is still more costly compared to 'static' queues, so this might be one opporTUNEity  .
As you obviously are using non-durable subscriptions, the dynamic queues should be removed automagically when your subscribing application closes the subscription. If it does this..... So please check if your subscriber applications do free all of their resources. You won't have this problem with a shared subscriber queue as the queue persists. Actually, the dynamic queues will be created by the subscriber, not by the broker (as far as I know). You should be able to see them on the queue manager your subscribers connect to as opposed to the broker queue manager (if they are different).
One last tuning tip would be to upgrade to V5.3 that was announced today (http://www-3.ibm.com/common/ssi/OIAccess?DocURL=http://d03xhttpcl001g.boulder.ibm.com/common/ssi/rep_ca/4/897/ENUS202-074/index.html&InfoType=AN&InfoSubType=CA).
The improvement list contains performance benefits for JMS. But that's probably a mid-term solution only.
Maybe some more seasoned JMS users can add to my thoughts.
Cheers,
Stefan
_________________
Stefan Sievert
IBM Certified * MQSeries
In the end everything is right. If not, it's not the end.
[ This Message was edited by: StefanSievert on 2002-04-10 13:25 ] |
|
| Back to top |
|
|
| tborrome |
| Posted: Wed Apr 10, 2002 2:21 pm Post subject: |
|
|
Novice
Joined: 03 Apr 2002
Posts: 17
|
stefan,
thanks again for your help. just found out that i was using mq for java 5.1.2 which defaulted to use the dynamic mutliple queue aproach. i moved to mc java 5.2 and hoefully, i'd get better performance with the shared queue approach.
i'm not to sure about upgrading to 5.3 yet - i'd have to evaluate that. do you know what performance improvements are offered in 5.3?
thanks again!
tyrone
|
|
| Back to top |
|
|
| StefanSievert |
| Posted: Wed Apr 10, 2002 2:32 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Tyrone,
they don't quantify that in the announcement (see my link above):
| Quote: |
Performance Improvements: Performance is optimized for general MQ operation and for JMS. Scalability and performance improvements offer more design choices for system designers.
The number of channels that can be used on a system is increased by Channel Process Pooling, where a small number of processes with a reasonable number of threads can now handle all channel operations, inbound and outbound.
Queues greater than 2 Gb are now supported, and at the same time the minimum queue footprint in memory is reduced from approximately 250 KB to 64 KB, to allow more queues to be opened at a time.
Performance for the WebSphere MQ SupportPacâ„¢ MA0C (publish and subscribe) is also enhanced.
|
MQ V5.3 won't be available before the end of June or even later, depending on the platform, so you can't upgrade now anyway. You won't need MA88 anymore, because it will be integrated into the product.
Cheers,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| 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
|
|
|
|
