Skip to main content

Tuning ActiveMQ for Performance

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:
  • Non-persisten messaging. Its atleast 20x faster. This can be achieved by:
  1. Set the NON_PERSISTENT message delivery flag on your MessageProducer.
  2. 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 

Popular posts from this blog

Why India Hasn’t Built Its GPT Moment (Yet)

India has the world’s third-largest startup ecosystem, a thriving developer base, and a mobile-first population larger than the US and Europe combined. Yet, no GPT-4. No DeepMind. No Amazon-style platform. Why? Innovation Isn’t Accidental—It’s Engineered The Zerodha Daily Brief recently asked why India hasn’t built a global product company like Apple. The key argument: India isn’t building for the world. It’s solving for local constraints, scale, and affordability—but global scale requires deep IP, design, and tech differentiation. It’s not just about software, it’s about systems thinking. More importantly, it answers the question: Why do countries innovate? The answer isn’t just genius or ambition—it’s incentives and ecosystems. The U.S. Defense Department, for example, accounted for nearly 70% of federal R&D funding during the Cold War. China has pumped billions into semiconductors and AI with long-term national alignment. These aren’t short-term bets—they are strategic, delibe...

From Stubborn to Smart: How I Learned to Use AI as a PM

Listen to the article in podcast format on PM-AI Diaries channel on Spotify! Ever since I published "The Death of the Stubborn PM" back in February, my inbox has been buzzing with one big question: “Okay, I get that AI is the future for product managers—but how do I actually use it?” It’s a fair ask. In that piece, I argued that PMs who resist AI are doomed to fade away, like dinosaurs refusing to evolve. As I wrote, “The stubborn PM who clings to old ways will die out, replaced by those who harness AI’s power while leaning into what makes us human.” Now, people want the playbook. So, let’s walk through it with a story—my own journey of figuring this out, backed by some sharp insights from MIT Sloan’s "When Humans and AI Work Best Together—and When Each Is Better Alone" . The Wake-Up Call Picture me a few months back: a PM buried in work, juggling a dozen tasks, and feeling like there weren’t enough hours in the day. Writing user stories, sketching ideas, track...

The Death of the Stubborn PM

Product Management is undergoing a seismic shift, much like programming did when compilers replaced assembly language or when Agile dismantled waterfall dogma. Stubborn PMs who cling to outdated rituals—like treating PRDs as sacred texts—will fade into irrelevance. The future belongs to those who embrace AI as a collaborator, not a threat.   AI Will Disrupt the Tactics, Not the Thinking   Historically, tools abstracted manual work: compilers automated code translation, A/B testing replaced gut-driven debates. Similarly, AI will automate tactical PM tasks—data aggregation, routine prioritization, even drafting specs. But this is liberating, not limiting.   The stubborn PM obsesses over *how* to write a PRD; the adaptive PM focuses on *why* a product should exist. AI can’t replicate judgment calls that demand intuition: interpreting unmet customer needs, balancing ethics with growth, or navigating ambiguity when data is sparse. As AI handles execution, the PM...