Queue Priorities

[pixel]

Hi

I have a system which has an http interface which takes a request, creates a wrapper object, and enqueues this object for asynchronous processing. When I hit this with a few requests everything works fine.

But when I start load testing, ie running 25+ concurrent threads each making 100+ connections one after the other, the time it takes to get a response from the request goes from 200-300 milliseconds to 5-15 seconds. If I disable the MDB on my queue, these times stay in the millis, so I know it's not tomcat that is causing the bottleneck.

What I want to know is if it is possible to lower the priority of the MDBs processing, without limiting the number of beans in the pool, so that the inbound request gets processed over an MDB.

If not, I think I may have to move my inbound request interface to another box, which puts requests on a remote queue, but I do not want to do this. The main concern is giving a response to the client making the request in the shortest time possible. This system will be periodically used to process 10000+ requests (by processing a CSV file) and I don't want to have to wait 5+ seconds per request

Thanks

pixel

[pixel]

Sorry, forgot to add: Running JBoss 3.2.7 on RedHat AS4, dual HT Xeons, 4gig ram, talking to an Oracle db

Thanks

[starksm64]

The logic of lowering the priority of the MDB escapes me. If slogging data between tomcat and the client is not the bottleneck, why shouldn't the priority be given to the MDBs? If your saturating the cpu on the box and this is the cause of the increased request latency, you certainly do need to scale the MDB tier to multiple boxes.

[pixel]

The CPU is not running at even close to 100%. To be honest, I can't figure out exactly where the bottleneck is, I only know that it goes if I turn off the MDB. We are using hibernate to perform lookups and update status as a message travels through the system, could this be causing a bottleneck?

[starksm64]

Sure. Profile the database server iteraction.

[schrouf]

you should verify your last hypothesis by simply outcommenting all processing code within the MDB and check request latency once again. If it is still high, that it's an indicator for the 'messaging bottelneck'.

Do you use persistent messages ? If so do you have enough connections in your connection pools ?

Regards
Ulf

[pixel]

we turned off a significant amount of db udpating, and we got a 3-4 fold performance increase, so it looks as though this is the problem. We are now going to spend the time tuning our database access some more.

Thanks for helping us identify this as the source of our problem.