As there are not a lot of fixes in 0.6.2, would you like me to identify the
culprit fix or do you prefer I test directly on 0.7.0?
For your information, we are currently compiling Proton 0.14.0 so we can use
the 0.7.0 but we still need some time before our code has been adapted.
From: Ted Ross <tr...@redhat.com>
Sent: Monday, October 10, 2016 7:08:36 PM
Subject: Re: [Dispatch router 0.6.2] Performance regression of the producers
It's not clear to me from looking over the commits which might have
caused the regression you have observed.
A little perspective on this question: 0.7.0 (now in RC1) is the first
release that has updates specifically targeted at increasing
performance. During the 0.7.0 development cycle, several significant
performance issues were identified and corrected.
Any performance regression is of interest and should be mentioned. That
said, the 0.7.0 release should exhibit considerably better performance
than the 0.6.x releases.
On 10/04/2016 04:39 AM, Adel Boutros wrote:
> In our performance tests, we use 4 Producers (3 JMS Producers + 1 Proton-c
> Producer) which all send messages synchronously to a messaging system
> composed of 1 Dispatcher connected to 2 Qpid Java Brokers (6.0.4). Producers
> send messages to a Topic which is bound on a queue (Binding Key + JMS
> selector filter: 67% of the events sent are accepted by the queue). 3 JMS
> Consumers are also attached to consume messages. The queue and topic are set
> on both brokers and the dispatch router advertises them correctly.
> Connection Schema
> Producers - - - - - | |--- Broker 1
> (3 JMS + 1 C++) | |
> |----- Dispatch Router---|
> Consumers - - - | |--- Broker 2
> (3 JMS)
> Dispatch Router has 4 connectors to each Broker.
> Dispatch Router + Brokers are on the same machines. Consumers + Producer are
> on the other machine.
> We have noticed a reduced overall average throughput of the producers by 3%
> by simply updating the version of the Dispatch Router from 0.6.1 to 0.6.2
> (The release candidate).
> Although the regression is tolerable but we would like to have your input on
> the above knowing that there are only 4 fixes between the above-mentioned
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org