Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid
 Java Broker 6.0.0
To: users@qpid.apache.org
References: <DUB112-W63C9AC1EA466B6680E12EBCD0D0@phx.gbl>
 <91a97928-ecea-5fdf-1e0f-f7a7b4079357@redhat.com>
 <DUB112-W8734FF3700A073DD2070D4CD0E0@phx.gbl>
 <ecb4d10d-c3f1-ddd6-0caa-3bb0f8a005a5@redhat.com>
 <DUB112-W133243D48B31C0AC9E70435CD010@phx.gbl>
 <b69b7897-4d7c-8ea0-f234-82f79f426fd4@redhat.com>
 <DUB112-W951567C9D299353723EC68CD050@phx.gbl>
 <29cc1cc6-c073-20bb-e417-02929c901711@redhat.com>
 <DUB112-W783CAE2FF63B6C2D9E0173CD050@phx.gbl>
 <DUB112-W78D52EAE06B8C1F67912CDCD050@phx.gbl>
 <031b31e0-ffb0-6e50-6dcf-ce664322f845@redhat.com>
 <1e321c97-9b5a-f9d7-8ad8-44b8b45050e3@redhat.com>
 <DUB112-W138944B891DF434B13521A5CD050@phx.gbl>
 <e200d838-e4d1-28b2-d892-1814b3d76ca9@redhat.com>
 <DUB112-W138A8624248B011ACE3A515CD050@phx.gbl>
 <DUB112-W136D89EC4B9ED9CAF4C04FCCD060@phx.gbl>
From: Ulf Lilleengen <lulf@redhat.com>
Message-ID: <104f6580-90cf-b3ee-dcb1-358168531ae7@redhat.com>
Date: Wed, 3 Aug 2016 16:23:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <DUB112-W136D89EC4B9ED9CAF4C04FCCD060@phx.gbl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 03 Aug 2016 14:23:18 -0000

Hi,

Excuse me if this was already mentioned somewhere, but what is the size 
of the messages you are sending 	?

FWIW, I'm able to get around 30-40k msgs/sec sustained with 1 producer, 
1 consumer, 1 dispatch (4 worker threads) and 1 broker (activemq-5). The 
sender sends unsettled messages as fast as it can using qpid-proton 
reactor API which is sending async up to the window limit.

With no broker involved, I'm getting ~190k msgs/sec.

All of these numbers are from my 8 core laptop. Message size is 128 bytes.

I don't know the dispatcher that well, but I think it should be able to 
handle data from each connector just fine given the numbers I have seen.

On 08/03/2016 02:41 PM, Adel Boutros wrote:
>
>
>
> Hello again,
>


> As requested, I added a 2nd connector and the appropriate autoLinks on the same host/port but with a different name. It seems to have resolved the issue.
>
> 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 msg/s.
> 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 msg/s.
> 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 msg/s.
>
> I think this confirms the problem is due to the fact a single connection is being shared by all clients (consumers/producers) and that having a sort of pool of connections or a connection per workerThread is a solution to consider.
>
> What do you think?
>
> I added a 3rd connector to see if it changes anything but it
> didn't.  Do you think this is maybe because the dispatcher is not able
> to process fast enough and saturate the 2 connectors?
> 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 msg/s.
>


> Adel
>
>> From: adelboutros@live.com
>> To: users@qpid.apache.org
>> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0
>> Date: Tue, 2 Aug 2016 22:21:54 +0200
>>
>> Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 workerThread but there wasn't a difference.
>> We want to benchmark in the worst case scenarios actually to see what is the minimum we can guarantee. This is why we are using synchronous sending. In the future, we will also benchmark with full SSL/SASL to see what impact it has on the performance.
>>> Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0
>>> To: users@qpid.apache.org
>>> From: gsim@redhat.com
>>> Date: Tue, 2 Aug 2016 20:41:54 +0100
>>>
>>> On 02/08/16 20:25, Adel Boutros wrote:
>>>> How about the tests we did with consumer/producers connected directly to the dispatcher without any broker where we had 16 000 msg/s with 4 producers. Is it also a very low value given that there is no persistence or storing here? It was also synchronous sending.
>>>
>>> The rate is low because it is synchronous. One messages is sent to the
>>> consumer who acknowledges it, the acknowledgement is then conveyed back
>>> to the sender who then can send the next message.
>>>
>>> The rate for a single producer through the router was 6,000 per second.
>>> That works out as a roundtrip time of 167 microsecs or so. In your
>>> table, the 16,000 rate was listed as being for 3 producers. Based on the
>>> rate of a single producer, the best you could hope for there is 3 *
>>> 6,000 i.e 18,000. (How many worker threads did you have on the router
>>> for that case?)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>  		 	   		
>
>  		 	   		
>

-- 
Ulf

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org