Recently I needed to optimize our ActiveMQ configuration for performance.
Let me explain our deployment, we had a Jetty based Java app with GWT for the UI. We use gwt-ActiveMq with long polling to send messages to the UI. We were using activemq for everything, for out SM design, or async event listener architecture. We have no plans to scale from more then one box and for us the performance is critical.
So things done were:
Bibligraphy:
Entire details is available in the webinar:
Rest of the details are in the below links:
Let me explain our deployment, we had a Jetty based Java app with GWT for the UI. We use gwt-ActiveMq with long polling to send messages to the UI. We were using activemq for everything, for out SM design, or async event listener architecture. We have no plans to scale from more then one box and for us the performance is critical.
So things done were:
- Non-persisten messaging. Its atleast 20x faster. This can be achieved by:
- Set the NON_PERSISTENT message delivery flag on your MessageProducer.
- Set the persistent=false flag in the
element of the Xml Configuration or on the property BrokerService.
- Remove the network. We used vm:// as transport so that the entire queue is in memory. No need to go over the network as our broker is embedded in the same context as the producer. You would have to change the broker address in the web.xml of the server as you won't get messages on the UI.
- Serialization is barrier to speed. We used vm as transport and configured objectMessageSerializationDefered to true. As we are using them on the same box, there is no point in serializing and deserializing the messages. This would allow us to use same hiberante objects across states. No need to clone and store them.
- Set alwaysSessionAsync=true. This reduces the context switching. There is lots of context switching which occurs when message is wrote on the queue and read from it.
- Set dispatchAsync=false. This again reduces context switching.
- Set optimizeAcknowledge=true. All the messages are acknowledged. This allows a more optimized way of acknowledging the messages. Need to explore more for exact implementation details.
- Don't prefetch messages in StateMachine. In case of our StateMachines, we always had 1 message which goes from one state to another. So, here there is no point prefetching messages.
- Prefetch Topic Listners. But with topics, its better to prefetch messages.
- Switch off flow control. If flow control is On, then the slowest consumers dictate the speed of the message. In activeMQ, the messages go into a message store as it is dispatched, if flow control is on, then the dispatch is done only on acknowledgments from the consumers and flow rate is determined based on the acknowledgments received.
Final Configuration:
<amq:broker id="broker" useJmx="false" persistent="false" useShutdownHook="true" schedulerSupport="true">
<amq:transportConnectors>
<amq:transportConnector uri="vm://localhost?async=false" />
</amq:transportConnectors>
</amq:broker>
<amq:connectionFactory id="jmsFactory" brokerURL="vm://localhost?async=false"
copyMessageOnSend="false" objectMessageSerializationDefered="true" alwaysSessionAsync="false"
dispatchAsync="false" optimizeAcknowledge="true" useAsyncSend="true" optimizedMessageDispatch="true"/>
Bibligraphy:
Entire details is available in the webinar:
http://download.progress.com/5331/open/adobe/prc/psc/perf_tuning_activemq/index.htm
Rest of the details are in the below links:
http://activemq.apache.org/how-should-i-use-the-vm-transport.html
http://activemq.apache.org/how-do-i-disable-persistence.html
https://code.google.com/p/gwt-activemq/http://activemq.apache.org/message-cursors.html