4 Replies Latest reply on Mar 5, 2014 9:53 PM by Justin Bertram

    Http remoting performance

    Sergei Egorov Newbie

      Hello everyone!

       

      I'm trying to use hornetq inside wildfly (i used standalone version before), and found some critical (for me) bottleneck - http-remoting-jmx performance is very slow. Our application handles thousands of requests per second, and each request it perform removeMessages on QueueControl thought remote JMX connection.

       

      With standalone HornetQ server everything is ok, but inside wildfly i got x20 performance regression. Is it possible to use old jndi jmx with wildfly? Or maybe tune http remoting for better performance?

       

      Thanks!

        • 1. Re: Http remoting performance
          Jeff Mesnil Master

          I'm confused by your post.

           

          Are you using JMX or messaging protocol to perform management operations on the QueueControl? If you are using JMX, there should be no performance cost compared to HornetQ standalone.

           

          If you are using the messaging protocol, you have 2 choices in WildFly:

          * use HornetQ native protocol (by configuring a remote-connector) and there should be no performance cost compared to HornetQ standalone

          * use HTTP Upgrade (by configuring a http-connector). In that case, there is an additional network round trip when *a connection is opened*.

           

          Have a look at the messaging subsystem documentation: Messaging configuration - WildFly 8 - Project Documentation Editor

           

          In any case, performing a management operation to call removeMessages() for every request looks like an anti pattern. Especially if you open a new connection for each operation.

          • 2. Re: Http remoting performance
            Justin Bertram Master

            Can you elaborate on your use-case where you need to invoke removeMessages for each request you handle?

             

            Also, how are you handling your JMX connections?  Are you re-using them?

            • 3. Re: Re: Http remoting performance
              Sergei Egorov Newbie

              Because of no ability for "last value queue" with scheduled delivery (i need scheduled delivery with "only last" message)

               

              Yes, i'm using JMX, not messaging management protocol.

               

              I'm using JMX with Spring JMX:

               

                          <bean class="org.springframework.jmx.support.MBeanServerConnectionFactoryBean">
                              <property name="serviceUrl" value="service:jmx:http-remoting-jmx://localhost:9991"/>
                              <property name="environment">
                                  <props>
                                      <prop key="#{T(javax.naming.Context).INITIAL_CONTEXT_FACTORY}">org.jboss.naming.remote.client.InitialContextFactory</prop>
                                  </props>
                              </property>
                          </bean>
              
              
              • 4. Re: Http remoting performance
                Justin Bertram Master

                Because of no ability for "last value queue" with scheduled delivery (i need scheduled delivery with "only last" message)

                I'm not sure what you mean by that.  Can you elaborate?

                 

                Yes, i'm using JMX, not messaging management protocol.

                Have you tried using HornetQ's management via Core API?

                 

                I'm using JMX with Spring JMX:

                That doesn't really answer my questions about how you're handling your JMX connections.