Hi Tomas, That does sound surprising. These performance tests[1] are run, with BDB and using the latest Qpid JMS Client, against both the Broker-J 7.0.0 and 6.1.4 code lines each day, which is consistently showing v7.0.0 is faster for the five use-cases exercised by the tests (see perftests/etc/testdefs/defaultTests.js). I am interested to hear about your use-case. Do you have code you can share?
cheers, Keith. [1] https://cwiki.apache.org/confluence/display/qpid/Running+Performance+Tests On 9 November 2017 at 15:21, Rob Godfrey <[email protected]> wrote: > Hi Tomas, > > are you saying that there is a significant degradation in performance > between 7.0.0 and prior versions for this scenario, or do you see the same > performance in 6.1.x? > > In terms of consuming - is the performance slow if you are consuming from a > queue with 1000 messages already in it, or is the slowness just caused by > the slow producer? > > Thanks, > Rob > > > On 9 November 2017 at 07:10, Vavricka <[email protected]> wrote: > >> Hi, >> >> we are testing release candidate of Java Broker 7.0.0. >> >> I checkout tag 7.0.0, build broker with tests without any problem. >> >> We have sender and receiver based on proton 0.18.1. >> Both sender and receiver are started at same time. >> Sender is sending 1000 persistent messages to exchange and receiver expects >> 1000 messages in queue. Messages have size 1 kB. >> We tried DERBY and BDB as persistent storage. >> >> Sending and consuming of durable messages is slow (10 messages per second). >> When sending non-persistent messages then broker behaves as expected. >> >> Is there some settings that can optimize persistent storage? >> >> Tomas >> >> >> >> -- >> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users- >> f2158936.html >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
