Posted: Sat Apr 30, 2005 3:24 am Post subject: slow performance
Newbie
Joined: 30 Apr 2005 Posts: 1
I have a queue whose depth might go upto 423000 records.
This queue is being consumed by an MDB and the messages are processed furthur and a database commit takes place there after. If i use a simple get without SYNCPOINT, there are chances that I would loose my message in the event of a failure after the message is removed from the queue. Hence i cannot do without SYNCPOINT. At the same time I cannot increase the number of MDB instances consuming the queue beyond a certain number. What could be a possible alternative to improve the performance in this scenario. Is there a way wherein i can get the messages without using SYNCPOINT and at the same time avoid the danger of lossing the message.
Joined: 27 Jan 2005 Posts: 397 Location: Philadelphia, PA
There are number of things you can do to improve performance from acceptable to drastic measures but all of them come at some cost.
1. Try tweaking max number of messages per transaction on your listener properties. Instead of commiting every 1 message perhaps you can commit ever 10 or so.
2. Your application probably has message affinity problems such that messages have to be processed in order. Try maybe changing the app so you dont have that affinity and you can many threaded listeners at once.
3. Are messages persistent? Do they need to be persistent?
4. You can disable transactioning all together and roll back the message yourself if you notice a problem with db insert. You can even play with priorities and have the message rolled back to the end or another queue with some error handling process.
5. Have you checked to make sure your mdb is not waiting on the db lock?
What are your database response times?
6. There is an option in the listener that allows listener to prebuffer messages into memory but process them only one a time. I recommend you go thoroughly through all mdb settings and connection factory, queue destination settings.
7. Divide workload from the business perspective. I had a customer who had to process about 2500 transactional MDB's per minute. Instead of processing all transactions from single queue using one listener, we set up 10 queues and 10 listener where messages where placed by the fron end based on the last digit of customer id. That way you are doing many things at once and still safe in most cases from message affinity problems. _________________ Mikhail Malamud
http://www.netflexity.com http://groups.google.com/group/qflex
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