I ran some benchmarks on JBoss 3.2.3 with JBossMQ version 3.2, and it seems as if the MDB layer in JBoss causes a serious slowdown.
All of the below was run on a Pentium-4 2.66Ghz with 512Mb RAM under Linux 2.6.6 with JDK 1.4.2_03.
I set up a single non-persistent queue, with a single deployed MDB EJB. The MDB was deployed with CMT, and the onMessage() method was marked as "NotSupported" transactions. At first I left the default pool size (15 MDBs), but adapted the JMS message cache store High and Max memory marks to make use of 256Mb RAM. I set the HSQLDB backend to be entirely in memory.
Posting 5000 messages to this queue takes around 16 seconds using the OIL2 Invocation Layer (or 312 messages per second), with both the client and the server running concurrently.
I then stopped the MDB consumer, and tested how long it takes a client to just send the messages to the queue - this takes around 12 seconds (or 416 messages per second)
After the queue was all filled up, I started delivery on the queue. 5000 messages to a single MDB took just under 30 seconds, or 185 messages per second consumed.
I then wrote a non-MDB JMS message listener and re-ran the last test. The entire queue (5000 messages) were dealt with in just over 13 seconds, or 385 messages per second.
I tried to disable the TracingInterceptor and the SecurityInterceptor, and increasing the size of the MDB pool from 15 to 25. This improved the situation slightly - the 5000 messages were dealt with in 25 seconds (or 200 messages per second).
This is still very bad when compared with the non-MDB client - there a single thread did 385 messages per second, while 25 MDBs did the same work at 200 messages per second.
All of my tests were done with non-persistent subscribers, and non-persistent messages.
I tried to use MySQL 4.0.x as the backend (running on the same computer) with MyISAM tables, but got worse performance than with the HSQL backend.
I have two questions:
1. What causes the MDBs to add such huge overhead?
2. How can the MDB overhead be reduced?