In an effort to keep all of the configuration within the code, my design for implementing asynchronous messaging failed our load tests. Our application was able to withstand 1400 hits per second before implementing ActiveMQ with the following model: * embedded JVM broker * non-persistent messaging * consumer took messages from producer with the same app and made httpClient sends to the remote machine using REST
After tweaking lots of settings we never made it above 800 hits/second. I then decided to RTFM and educate myself on Enterprise Integration Patterns. The new design is much simpler and my hope is that it will increase our application performance because... 1) The processing of the queue will now be outside of my application's JVM 2) My application will not function as both a producer and a consumer 3) The consumer will not be making httpClient (hence using more threads) 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--tp27168341p27168341.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
