On Jan 5, 2012 11:45 AM, Rob Godfrey rob.j.godf...@gmail.com wrote:
On 4 January 2012 22:56, Rob Godfrey rob.j.godf...@gmail.com wrote:
In terms of BDB vs. Derby performance, I wouldn't be surprised if for a
single producer / single consumer case the performance is very similar.
As
On 4 January 2012 22:56, Rob Godfrey rob.j.godf...@gmail.com wrote:
In terms of BDB vs. Derby performance, I wouldn't be surprised if for a
single producer / single consumer case the performance is very similar. As
Robbie highlights, really the performance here is all to do with how often
Hi Rob,
Thanks for taking a deeper look into this.
Your results are very interesting. I've not tested the case of
multiple consumers/producers and the throughput in that case for BDB. I
will try to simulate
a test and see if I can get similar results.
Thank you,
Praveen
On Thu, Jan 5, 2012 at
Hi Praveen,
I was using the head of trunk at the time of sending the message, and
was testing with your test classes. Persistent messaging performance
is almost entirely dependant on your storage, so down to a certain
extreme you wont really see any difference with varying memory or cpu
Thanks for writing Robbie. That explains.
On Wed, Jan 4, 2012 at 1:11 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
Hi Praveen,
I was using the head of trunk at the time of sending the message, and
was testing with your test classes. Persistent messaging performance
is almost entirely
In terms of BDB vs. Derby performance, I wouldn't be surprised if for a
single producer / single consumer case the performance is very similar. As
Robbie highlights, really the performance here is all to do with how often
you can synchronously write to disk. If ach store is performing a single
Hi Robbie,
Thank you for the mail. I will try using the latest changes to grab the
recent
performance tweaks and run my tests over again.
Yep, I made the test enqueue and dequeue at the same time, as I was trying
to simulate
something close to how it'd work in production. I do know that the
Hi Praveen,
I notice both your tests actually seem to enqueue and dequeue messages
at the same time (since you commit per publish and the message
listeners will already be recieving a message which then gets commited
by the next publish due to the single session in use, leaving a
message on the
Hi,
I've been trying to benchmark the BerkeleyDb against DerbyDb with the
java broker to find which DB is more perform-ant against the java broker.
I have heard from earlier discussing that berkeleydb runs faster in the
scalability tests of Qpid. However, some of my tests showed the contrary.
