kevin - peek at https://issues.apache.org/jira/browse/AMQ-5578 it gives a big win in terms of OS system work per journal write, it is however kahadb focused at the moment.
To drive the disk, the more parallel work that the brokers can introduce the better. In other words, to get max throughput, you can increase the num of parallel jms connections per destination, the the number of destinations per broker, then the number of brokers. At each stage track peek throughput till it starts to drop off before introducing the next level of parallelism. A broker will try and batch writes but it needs parallel connections and or destinations to do that. With SSD, write performance may not be the bottleneck, but working through a process like the above will identify what is. On 13 March 2015 at 03:00, Kevin Burton <bur...@spinn3r.com> wrote: > I’m trying to improve our ActiveMQ message throughput and I’m not really > seeing the performance I would expect. > > We moved from non-persistent to persistent (which would be more ideal) and > the performance is about 4-5x slower than before. > > I think this would be somewhat reasonable but our disks aren’t really at > 100% utilization and they’re on SSD. They’re only at about 5% utilization. > > So perhaps instead of ONE ActiveMQ node on a 16 core box it might be more > beneficial to use say 4 or 8 ? (maybe putting them in containers). > > Granted this would require a TON of work right now, but that might be the > best way to go (in theory). > > Kevin > > -- > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> > <http://spinn3r.com>
