qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Praveen M <lefthandma...@gmail.com>
Subject Re: DerbyDB vs BerkeleyDB using the Java Broker
Date Fri, 06 Jan 2012 03:18:45 GMT
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,

On Thu, Jan 5, 2012 at 10:44 AM, Rob Godfrey <rob.j.godfrey@gmail.com>wrote:

> On 4 January 2012 22:56, Rob Godfrey <rob.j.godfrey@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
> > you can synchronously write to disk.  If ach store is performing a single
> > write to disk for each transactional commit, then the performance should
> be
> > very smilar.
> >
> >
> So, I actually spent a bit of time today testing this out :-)
> The use case that my users most often encounter with persistent messaging
> is where each message sent/received from the broker is sent in its own
> transaction (using JMS), and for the testing I have chosen a 1Kb message
> size.
> The Derby store does indeed provide slightly superior performance if you
> have eight or less active connections, but the BDB store scales better
> above that number. For completeness I have also tested the C++ broker with
> its async store, and another popular AMQP broker implementation
> You can see the results here:
> https://docs.google.com/spreadsheet/pub?hl=en_GB&hl=en_GB&key=0AqizD3Y_JixzdFhKZFctbzRWbWtMbE9CcnJzWjZMQVE&output=html#
> Note that other test scenarios (in particular not using transactions) would
> likely give wildly different comparative performance, and message sizes may
> also affect the results.  Obviously people should always test on their own
> hardware and with test cases reflecting their actual usage pattern.
> Cheers,
> Rob


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