2 Replies Latest reply on Nov 30, 2012 4:13 AM by venkatesh grandhi

    Hornetq Performance on Windows

    venkatesh grandhi Newbie

      Hi everyone,I am runnning Hornetq on Windows 7 Operating System...the scenario is I am using Topic for publish/subscribe....i am using a non-clustered environment and as the required is zero msg loss...I used <persistence-enabled>true </persistence-enabled> so that when a subscribe goes inactive mode ..there should be no msg loss and I am able to get all the msgs...the problem is when I am using persistence the performance is extremely low(27msgs/sec) even though the disk writing is on the same system....so can anybody helpme out in this...

       

      System Configurations

      -----------------------------------

      OS:Window7

      Processor-Intel(R) Core(TM) i3-2100  CPU@3.10GHz

      Ram -4GB

        • 1. Re: Hornetq Performance on Windows
          Clebert Suconic Master

          This is not about Windows or Linux...

           

          HornetQ is optimized to scale up to many simultaneous producers and many simulatenous committers... but for any single source, we still have to keep the guarantees promised on the interface.

           

          This is actually the same with most system. Even a database is optimized in the same manner. a single thread will be able to only perform 24 transactions or less per second (committs) due to the disk capabilities on sync. If you have a system doing anything beyond your hardware it's probably cheating.

           

           

          that means: when you commit, we won't unblock until the hardware has finished committing.

           

           

          Most fast hardware can do about 24 syncs per second, and that's what you are seeing here:

           

           

          If you had two parallel producers, both should go around 24 syncs since the server will try to batch both writes in a single sync on disk.

           

           

           

          So, in your test, if you batch your committs, you will get a much faster throughput:

           

           

                          if (i % 1000 == 0 && i > 0)

                           {

                               session.commit();

                           }

           

           

          And make sure you commit the last transaction at the end.

          1 of 1 people found this helpful
          • 2. Re: Hornetq Performance on Windows
            venkatesh grandhi Newbie

            Clebert Suconic wrote:

             

            This is not about Windows or Linux...

             

            HornetQ is optimized to scale up to many simultaneous producers and many simulatenous committers... but for any single source, we still have to keep the guarantees promised on the interface.

             

            This is actually the same with most system. Even a database is optimized in the same manner. a single thread will be able to only perform 24 transactions or less per second (committs) due to the disk capabilities on sync. If you have a system doing anything beyond your hardware it's probably cheating.

             

             

            that means: when you commit, we won't unblock until the hardware has finished committing.

             

             

            Most fast hardware can do about 24 syncs per second, and that's what you are seeing here:

             

             

            If you had two parallel producers, both should go around 24 syncs since the server will try to batch both writes in a single sync on disk.

             

             

             

            So, in your test, if you batch your committs, you will get a much faster throughput:

             

             

                            if (i % 1000 == 0 && i > 0)

                             {

                                 session.commit();

                             }

             

             

            And make sure you commit the last transaction at the end.

            ThankQ Clebert for your timely response...the throughput has been increased a lot....and knowledege of sync writes is very informative...