13 Replies Latest reply on Jun 22, 2007 7:56 AM by dmarchant

    JBossESB performance

    jumanji

      Hi, everybody!

      I'm trying to find out if JBossESB meets our client's requirements. Among other things they want - well, you know - "fast esb". And I've got some problems with it.
      I've run some tests with simple configuration: just 2 services, first one receives esb-unaware message (jms) ant routes in to the second one (using StaticRouter). Service 2 displays message on console (using NotifyConsole).

      jbossesb.xml file looks like that:

      <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.xsd" parameterReloadSecs="5">
      
       <providers>
       <jms-provider name="JBossMQ" connection-factory="ConnectionFactory"
       jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
       jndi-URL="localhost" >
      
       <jms-bus busid="quickstartGwChannel">
       <jms-message-filter
       dest-type="QUEUE"
       dest-name="queue/frontoffice_Request"
       />
       </jms-bus>
       <jms-bus busid="quickstartEsbChannel">
       <jms-message-filter
       dest-type="QUEUE"
       dest-name="queue/B"
       />
       </jms-bus>
       <jms-bus busid="channel">
       <jms-message-filter
       dest-type="QUEUE"
       dest-name="queue/A"
       />
       </jms-bus>
       </jms-provider>
       </providers>
      
       <services>
       <service
       category="FirstServiceESB"
       name="SimpleListener"
       description="Hello World">
       <listeners>
       <jms-listener name="JMS-Gateway"
       busidref="quickstartGwChannel"
       maxThreads="1"
       is-gateway="true"
       />
       <jms-listener name="helloWorld"
       busidref="quickstartEsbChannel"
       maxThreads="1"
       />
       </listeners>
       <actions>
       <action name="routeAction"
       class="org.jboss.soa.esb.actions.StaticRouter">
       <property name="destinations">
       <route-to service-category="SecondServiceESB"
       service-name="SecondService"/>
       </property>
       </action>
       </actions>
       </service>
       <service
       category="SecondServiceESB"
       name="SecondService"
       description="Hello World">
       <listeners>
       <jms-listener name="tatata"
       busidref="channel"
       maxThreads="1"
       />
       </listeners>
       <actions>
       <action name="notificationAction" class="org.jboss.soa.esb.actions.Notifier">
       <property name="okMethod"
       value="notifyOK"/>
       <property name="notification-details">
       <NotificationList type="OK">
       <target class="NotifyConsole"/>
       </NotificationList>
       </property>
       </action>
       </actions>
       </service>
       </services>
      </jbossesb>
      
      


      I put 200 short messages (about 2 KB) in jms queue "queue/frontoffice_Request" ant it takes esb (v. 4.0 GA) about 30 seconds to handle them. The question is - "is this normal?" Or I'm just doing something wrong.

      I've tried JBossESB 4.2 MR2, too. It is faster, but not significantly (200 messages - 20 seconds).

      Thank you for answers and sorry for my English -))))),

      J

        • 1. Re: JBossESB performance
          system.out

          This benchmark is very critical for us as well. I am specially interested to see a comparison with other ESB frameworks !
          Mike

          • 2. Re: JBossESB performance
            kurtstam

            We have jmeter scenario checked into: http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/qa/jmeter/ which seems pretty similar to what you have. Let me rerun it to get you the current throughput and response times.

            --Kurt

            • 3. Re: JBossESB performance
              marklittle

              I would not recommend JBossMQ as the fastest JMS implementation we support. Can you use JBoss Messaging, since we also support that and it is much faster than JBossMQ.

              • 4. Re: JBossESB performance
                kurtstam

                Running the Helloworld-Action.jmx and JBossMessaging, loading with 20 threads, and *everything* runnning on a little laptop I see a throughput of roughly 3000 to 4000 msg/min and response times of 200-400 ms. It slows down a bit over time as the gb needs to work harder. This is before I do any tuning.

                --Kurt

                • 5. Re: JBossESB performance
                  marklittle

                  What's a "little laptop" ;-)?

                  • 6. Re: JBossESB performance
                    kurtstam

                    Buy me a new machine and our performance story gets better :). Seems like cheap marketing dollars to me.

                    • 7. Re: JBossESB performance
                      marklittle

                      If "little laptop" is your works machine then it ain't little ;-)

                      • 8. Re: JBossESB performance
                        jumanji

                        Hi everybody and thank you for answers!

                        But I still have some questions ^^

                        I've run my sample with profiler and got this result:

                        [img]http://farm2.static.flickr.com/1269/580928526_f041c92580_o.jpg[/img]

                        Will JBossMessaging solve my problems? -)

                        (Simple helloworld without sending messages between services works pretty fast.)

                        Thank you again,
                        J

                        • 9. Re: JBossESB performance
                          kconner

                           

                          "jumanji" wrote:
                          Will JBossMessaging solve my problems? -)


                          Our experience is that JBoss Messaging is much faster. If that is your problem then it may solve it ;)

                          If you still have problems with JBoss Messaging then send us a testcase and we will look at it. You should install version 1.3.0 of JBoss Messaging.

                          • 10. Re: JBossESB performance
                            jumanji

                            On snapshot I see that method java.net.SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) consumes 73% of cpu's time. I believe it is not concerned with JMS, or is it? Could you tell me what this method is for?



                            • 11. Re: JBossESB performance
                              kconner

                               

                              "jumanji" wrote:
                              java.net.SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) consumes 73% of cpu's time.

                              It is the native method which reads from an incoming stream. This is almost certainly an I/O wait and should not consume any CPU time.

                              Can you please try JBoss Messaging and see if you have the same issues?

                              • 12. Re: JBossESB performance
                                jumanji

                                ok. thank you very much!

                                • 13. Re: JBossESB performance

                                  Is there a bunch of other things on your machine running using the network?

                                  By the way 73% is the percentage of time from the whole run and doesn't really indicate that it is taking 73% of your CPU. It is taken 73% of CPU time of the particular run's total CPU time (1381227 ms ) looks like about 164 ms per invocation of reading from the socket.

                                  This makes sense since anything opening a socket or file is going to have to fight for resources on the actual OS. Take a look at log4j's file writing as an example as well.

                                  What you should look at is memory as well. How did you run the test on a clean box?

                                  Also what is the size of your message? ( I assume about 6 k)

                                  Are you sending about 200 messages through the bus for the test?

                                  It looks like it takes about 4988 ms per total message read.