6 Replies Latest reply on Jul 20, 2004 4:50 AM by stephanenicoll

    MDBs incur a tremendous overhead (JBoss 3.2.3)

    lokman

      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.

      Details:
      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?


      Thanks,
      Lior

        • 1. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)

          Your tests seems interesting. I just have one question: if you use non persistent messages, why are you considering databases?

          Regards,

          Stephane

          • 2. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)
            lokman

            I consider a database for the PersistenceManager because JBossMQ (a la JBoss 3.2.3) uses one regardless of whether the messages sent are persistent or not.

            If the messages in the MessageCache consume too much memory, then messages are passivated into the PersistenceManager, even if they were sent as non-persistent.

            In my tests, while using MySQL I could frequently see that messages are inserted and deleted into the database. Also, the MDB invoker uses "java:/XAConnectionFactory" to connect to JMS, so there is a matter of transaction information that is always saved in JMS_TRANSACTIONS.


            Lior

            • 3. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)

              Ah ok, I didn't knew.

              Thanks,

              Stephane

              • 4. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)
                genman


                You can use a PersistenceManager that doesn't persist anything.

                org/jboss/mq/pm/none/PersistenceManager.java

                You will also get better throughput if you use less threads, or the same amount of threads as you have processors.

                • 5. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)
                  lokman

                   

                  "genman" wrote:

                  You can use a PersistenceManager that doesn't persist anything.

                  org/jboss/mq/pm/none/PersistenceManager.java

                  This means that if the stress level is high enough, I can lose messages. That's not my purpose - I don't want to lose messages - I also don't care to save messages between server restarts.


                  You will also get better throughput if you use less threads, or the same amount of threads as you have processors.


                  The whole point in the MDB idea is that you have a pool of consumers on the queue. Using less threads means less consumers and should mean worse performance, not better performance.

                  Thanks,
                  Lior


                  • 6. Re: MDBs incur a tremendous overhead (JBoss 3.2.3)

                     

                    "lokman" wrote:
                    The whole point in the MDB idea is that you have a pool of consumers on the queue. Using less threads means less consumers and should mean worse performance, not better performance.


                    Provided that your consumers will not run into some concurrency issues (while processing messages)

                    Regards,

                    Stephane