Just to add - I switched from using the default (journal+derbydb) to Kaha. Wow - what a difference. The derbydb, once the checkpointing starts, very much gets in the way. I think we probably have fairly slow disks in the dev env we were testing on, but nevertheless, switching to Kaha was night-and-day. On a fairly slow machine, 8 cpu's at 1.349ghz, we could get a little over 1000/sec (not sure of message size off the top of my head, but not big/not little - maybe 1k?) between one producer and one consumer.
James.Strachan wrote: > > On 10/11/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote: >> Hi James, >> >> > Am wondering if you're hitting a slightly different issue though - of >> > the RAM / gc impact of using the journal causing pauses versus the >> > much simpler write to JDBC >> >> Could be. The test cases run from pretty small to pretty large and they >> all >> seem to have the same results. I'm doing the tests on my dev box but >> hopefully we'll get a chance to do more on a box that matches our >> production >> scenario a little better (remote sql server, dedicated box, lots of >> memory) >> and I'll see what the numbers look like between them and get them back to >> you. >> >> > BTW it'd be interesting to see the performance if you tried kaha >> > instead of JDBC, just to get an idea of relative speed >> >> Will do as soon as we move to 4.1 (I assume it's only available in 4.1) >> and >> get back to you with the results. That said, as soon as 4.1 goes live, >> we're >> going to move to Shared JDBC Master / Slave which is why I was trying to >> get >> an idea of what the performance of pure JDBC was like. > > Yeah - its a very cool option :) > > Thanks for the heads up - I was just nosy to find out kaha v JDBC with > SQLServer :) > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/surprising-performance-tuning-result-with-activemq-4.0.1-tf2422666.html#a6783898 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
