activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie McCrindle" <jamiemccrin...@gmail.com>
Subject Re: surprising performance tuning result with activemq 4.0.1
Date Wed, 11 Oct 2006 13:53:37 GMT
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.

cheers,
j.

On 10/11/06, James Strachan <james.strachan@gmail.com> wrote:
>
> On 10/11/06, Jamie McCrindle <jamiemccrindle@gmail.com> wrote:
> > in the test, yes it is.
>
> OK - I just wondered that maybe the journal was on a slower/heavily
> used disk and SQLServer was using a faster one :0
>
>
> > would the journal and sqlserver be queing behind
> > each other for io?
>
> The ideal scenario for using the journal is for it to use a dedicated
> disk and be the only writer, so the disk head doesn't need to do
> seeks, it can just keep writing to the end of a file etc.
>
> 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
>
> BTW it'd be interesting to see the performance if you tried kaha
> instead of JDBC, just to get an idea of relative speed
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message