| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQSeries PubSub performance |
« View previous topic :: View next topic » |
| Author |
Message
|
| tborrome |
 Posted: Fri Apr 05, 2002 3:34 pm Post subject: |
 |
|
Novice
Joined: 03 Apr 2002
Posts: 17
|
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 |
|
 |
| kdavis |
| Posted: Thu Apr 03, 2003 8:28 am Post subject: |
|
|
Novice
Joined: 09 Dec 2002
Posts: 13
|
If you are using durable subscribers and they aren't running, your under pinning queues will get very big. If durablilty isn't an issue, then you can create the topic subscribers as non-durable...
Also, if you're subsccribers are performing many operations like XSLT, they may be much slower then you publisher -- you will need to consider concurrent processing to keep up. Either get the message from the subscription and commit, then kick off a processor on it's own thread and handle failure in such a way as to preserve the proper guaranteed delivery, or use some other stategy like having the subscription write the message to a local queue, and move on, letting some other process deal with the queues. These answers may or may not apply -- I don't know what the app is supposed to do.
Our experience has been that the JMS is pretty fast. Were dealing with tens of thousands of messages per month. Again, the processing done by the subscriber or publisher is the limiting factor.
We do bump the SYSTEM.BROKER.DEFAULT.STREAM max messages up to 50000 as a safety valve. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 03, 2003 8:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, the Websphere MQSeries Event Broker product is a highly optimized pub/sub broker engine that will run significantly faster than the base MQ Series pub/sub broker. And I think it offers enhanced subscription capabilities, too.
Of course, it's not free. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Apr 03, 2003 11:54 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
If you only have 100 subscribers and you are seeing around 1000 *.3CADD queues, then it sounds like you have durable subscribers that have left and didn't deregister. There is a dumpbroker program at
http://www.developer.ibm.com/tech/sampmq.html
that you can use to see who is subscribed. There is also a companion program (Unsubscribe) that you can use to remove subscriptions.
Another thing to look into from a performance standpoint is persistent vs. non-persistent messages. Depending on what you are doing, you might be able to get away with using non-persistent messages which will also speed things up. The T(opic) has a a persistence property that you can set with JMSAdmin. |
|
| 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
|
|
|
|
