activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jongraf <>
Subject Re: Poor design, poor performance. Better design, better performance?
Date Tue, 19 Jan 2010 23:13:03 GMT

Our load tests have completed and I am proud to report that reading the
documentation, educating the entire technical team and documenting the
various ActiveMQ settings in our properties files has led to a significant
performance increase.

Our web app hit 1750 hits per second with 1,000 virtual users.  This is way
better than what we were getting with embedded brokers in each JVM with
consumers talking to each other via REST.  

Lessons: simple architecture, less layers and reading, reading, reading. 

Read the various enterprise integration patterns and pick one that suits
your needs.
In my case:

Learn about the various ActiveMQ Topologies:
(this should probably be the first page of the documentation)

Many of the Spring examples show the Producer beans and the Consumer beans
in the same Spring XML.  In a client-server topology, this is a highly
unlikely scenario.  Your producer and consumer will live in separate .war

jongraf wrote:
> Proposed design:
> * client-server topology with standalone broker
> * non-persistent messaging
> * producer client sends to queue, consumer client on remote machine
> listens to queue
> Does my thought process make sense?  I am not necessarily looking to
> increase the number of messages sent through the queue, but to allow my
> application to have better response times.

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message