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! Read the various enterprise integration patterns and pick one that suits your needs. In my case: http://www.enterpriseintegrationpatterns.com/Message.html Learn about the various ActiveMQ Topologies: http://activemq.apache.org/topologies.html (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 distributions. 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: http://old.nabble.com/Poor-design%2C-poor-performance.--Better-design%2C-better-performance--tp27168341p27234416.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
