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 <[EMAIL PROTECTED]> wrote:
On 10/11/06, Jamie McCrindle <[EMAIL PROTECTED]> 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/
