Help: Queues Consumption Performance Paradox - can JBoss mak

[ivanvaghi]

I hope someone in the forum can give us a hand on this.

We have been using jboss for some time in a project, mainly as a JMS server.

However we have now hit a performance problem that we cannot solve and that does not appear on other application servers.

Our architecture has a producer of "jobs" that are put on a queue. Several consumers, from the same or different PCs can get jobs from the queue and carry them out. This architecture was designed to allow the plug-in of processing power on demand.

However, as we started adding consumers, processing times started to increase linearly with the number of consumers rather than decreasing!

This has put us in a position where either we solve the problem or we have to switch to a different application server... which we don't really want to do.

Do you guys have any advice on how to solve this?

Thanks,

Ivan

[alchemista]

There are several performance problems with JbossMQ, but nobody seems to offer solutions.

I did find that some v4 changes were backported to 3.2.0RC1, and that some of those included cache improvements. We noticed that 3.2.0RC1 did better under load than any previous version (where previous versions would simply die under load).

I suggest checking 3.2.0RC1 out and report back results.

[ivanvaghi]

Does anybody know of any alternative free or low-cost JMS server that can be easily plugged-in jboss and does not show this multiple consumers performance problem?

Do you know how to carry out the integration with Jboss?

Thanks,
Ivan

[joelvogt]

well hang on :) Lets look at your problem a little more first. When you say processing time increases, what time do you mean? Sending, receiving, before or after etc?

[ivanvaghi]

Hi Joel, thanks for answering.

I was referring to the receiving time. First we fill up the queue, then we run a number of JMS clients both on a multiprocessor machine and other PCs on the LAN. The clients dequeue the messages, do some JDBS accesses and then process the messages.

The processing time is negligible compared to the DB accesses and the JMS connection.

If it takes me 100 seconds to empty a queue using one client, it takes me about 200 seconds when I use two clients, and about 300 seconds with 3 clients.

This defies the purpose of putting the messages on a single queue for distributed consumption... we solved the problem splitting the queue in many smaller queues, and getting different clients on different queues, but this approach is inflexible and not very scaleable, requiring manual fine-tuning.

Thanks in advance for any help!