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 dequeue throughput rate is not a very accurate one. :) But yeah, like you said, all I was trying to check is more of which one performs better berkeley/derby. Given that derby outperforms berkeley for some use cases, what would be your recommendation to use as a persistant store? I understand that berkeley is used more widely than derby in production by various users of qpid. Would that mean berkeley can be expected to be a sheer more robust a product as it might have been tested more thorough?? Would you have a recommendation for picking one over the other as the MessageStore? Thanks to you and the rest of the team for the work that you guys are putting together towards performance tuning the product. - Praveen On Sun, Dec 18, 2011 at 6:31 PM, Robbie Gemmell <[email protected]>wrote: > 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 queue at the end), so you might not be getting the > precise number you are looking for in the first test, but that doesnt > really change the relative results it gives. > > I didnt see quite the same disparity when I ran the tests on my box, > but the Derby store did still win significantly (giving ~2.3 vs 4.4ms > and 350 vs 600msg/s best cases), though there have been some changes > made on trunk since your runs to massively improve transient messaging > performance of the Java broker which may also have influenced things > here a little. Either way, although it makes the test suite runs take > significantly longer it would seem that in actual use the Derby store > is currently noticably faster in at least some use cases. As I have > said previously our attention to performance of the Java broker has > been lacking for a while, but we are going to spend some quality time > looking at performance testing very soon now, and given the recent > transient improvements will undoubtedly be looking at persistent > performance going forward as well. > > Robbie > > On 3 December 2011 00:45, Praveen M <[email protected]> wrote: > > 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. > > > > I had setup BDB using the "ant build release-bin -Dmodules.opt=bdbstore > > -Ddownload-bdb=true" as directed in Robbie's earlier email in a similar > > topic thread. > > > > I tried running two tests in particular which are of interest to me > > > > Test 1) > > Produce 1000 messages to the broker in transacted mode such that after > every > > enqueue you commit the transaction. > > > > The time taken to enqueue a message in transacted mode from the above > test > > is approx 5-8 ms for derbyDb and about 18-25 ms in the case of > BerkeleyDb. > > > > > > Test 2) > > Produce 1000 messages with auto-ack mode, with a consumer already setup > for > > the queue. > > When the 1000th message is processed, calculate it's latency by doing > > Latency = (System.currentTimeInMillis() - message.getJMSTimeStamp()). > > > > Try to compute an *approximate* dequeue rate by doing > > numberOfMessageProcessed/Latency. > > > > In the above test, the results I got were such that, > > > > DerbyDb - 300 - 350 messages/second > > BDB - 40 - 50 messages/second > > > > > > I ran the tests against trunk(12/1) > > > > My Connection to Qpid has a max prefetch of 1 (as my use case requires > this) > > and has tcp_nodelay set to true. > > > > I have attached the tests that I used for reference. > > > > Can someone please tell me if I'm doing something wrong in the above > tests > > or if there is an additional configuration that I'm missing? > > > > Or are these results valid..? If valid, it will be great if the > difference > > could be explained. > > > > Hoping to hear soon. > > > > Thank you, > > -- > > -Praveen > > > > > > --------------------------------------------------------------------- > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- -Praveen
