Dispatch Router throughput

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Hi,

we are currently doing some baseline throughput testing with Dispatch Router 0.8.0.
In the course of doing so, we wondered what number of messages we should be able to expect being processed by a single Dispatch Router instance in its default configuration, i.e. link capacity 250, 4 worker threads, running on a core i7 @2.2GHz.

Let's say we have a single sender, sending pre-settled messages with a payload of 20 bytes and a single receiver for the messages.

If all is correctly setup, what number of messages could we expect going through Dispatch Router? I am merely interested in an order of magnitude. Are we talkinng about 1.000s, 10.000s or 100.000s per second?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Gordon Sim
On 13/07/17 15:20, Hudalla Kai (INST/ECS4) wrote:
> Let's say we have a single sender, sending pre-settled messages with a payload of 20 bytes and a single receiver for the messages.
>
> If all is correctly setup, what number of messages could we expect going through Dispatch Router? I am merely interested in an order of magnitude. Are we talkinng about 1.000s, 10.000s or 100.000s per second?

It depends on the client used.

I haven't actually measured performance with pre-settled messages (not
sure if anyone else can comment on that case specifically) but for
unsettled messages, a single sender and receiver using qpid::messaging
c++, I would expect 80-90k msgs/sec.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Chuck Rolke
In reply to this post by Hudalla Kai (INST/ESY1)
Hi,

I have a setup on my laptop (Lenovo W541, core i7 @2.8GHz, 16Gb) and I can run:
 1. single router 0.8.x; 4 worker threads
 2. a qpid-proton C++ simple-send sender; message body is string "abc"
 3. a amqpdotnet client running under mono, initial-credit 250

Sending to address { prefix: q1-multicast, distribution: multicast } : 40,000 m/sec
Sending to address { prefix: q1-balanced,  distribution: balanced  } : 61,000 m/sec
Sending to address { prefix: q1-closest,   distribution: closest   } : 61,000 m/sec

The setup gets *relative* performance numbers while I fiddle with the code.

HTH,
Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, July 13, 2017 10:20:09 AM
> Subject: Dispatch Router throughput
>
> Hi,
>
> we are currently doing some baseline throughput testing with Dispatch Router
> 0.8.0.
> In the course of doing so, we wondered what number of messages we should be
> able to expect being processed by a single Dispatch Router instance in its
> default configuration, i.e. link capacity 250, 4 worker threads, running on
> a core i7 @2.2GHz.
>
> Let's say we have a single sender, sending pre-settled messages with a
> payload of 20 bytes and a single receiver for the messages.
>
> If all is correctly setup, what number of messages could we expect going
> through Dispatch Router? I am merely interested in an order of magnitude.
> Are we talkinng about 1.000s, 10.000s or 100.000s per second?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Adel Boutros
Hello,


I think it depends on how you are using the Dispatch Router. From Gordon's and Chuck's reply, they assumed you were talking about peer-to-peer communication using the Dispatch Router which is a very useful use case.


However, if like us, you have an actual broker connected via the dispatch router using waypointed addresses, then the throughput will drop even if you scale the worker thread because in that case, you would also need to scale the connectors and reduce network latency between the broker and the dispatch router.


So I would say the throughput depends on the configuration and architecture of your system.


Regards,

Adel

________________________________
From: Chuck Rolke <[hidden email]>
Sent: Thursday, July 13, 2017 4:59:25 PM
To: [hidden email]
Subject: Re: Dispatch Router throughput

Hi,

I have a setup on my laptop (Lenovo W541, core i7 @2.8GHz, 16Gb) and I can run:
 1. single router 0.8.x; 4 worker threads
 2. a qpid-proton C++ simple-send sender; message body is string "abc"
 3. a amqpdotnet client running under mono, initial-credit 250

Sending to address { prefix: q1-multicast, distribution: multicast } : 40,000 m/sec
Sending to address { prefix: q1-balanced,  distribution: balanced  } : 61,000 m/sec
Sending to address { prefix: q1-closest,   distribution: closest   } : 61,000 m/sec

The setup gets *relative* performance numbers while I fiddle with the code.

HTH,
Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, July 13, 2017 10:20:09 AM
> Subject: Dispatch Router throughput
>
> Hi,
>
> we are currently doing some baseline throughput testing with Dispatch Router
> 0.8.0.
> In the course of doing so, we wondered what number of messages we should be
> able to expect being processed by a single Dispatch Router instance in its
> default configuration, i.e. link capacity 250, 4 worker threads, running on
> a core i7 @2.2GHz.
>
> Let's say we have a single sender, sending pre-settled messages with a
> payload of 20 bytes and a single receiver for the messages.
>
> If all is correctly setup, what number of messages could we expect going
> through Dispatch Router? I am merely interested in an order of magnitude.
> Are we talkinng about 1.000s, 10.000s or 100.000s per second?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com<http://www.bosch-si.com>
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
In reply to this post by Chuck Rolke
Hi Chuck,

this is indeed very helpful and it is in the same ball park as I expected.
Sadly, though, it doesn't at all match what we are experiencing using a vertx-proton based Java sender and consumer where we currently seem to not get above 2500 m/sec. I hope that either our test setup is completely wrong or that our usage of vertx-proton is erroneous.

Does anybody have some experience using vertx-proton with Dispatch Router?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Chuck Rolke <[hidden email]>
Sent: Thursday, July 13, 2017 16:59
To: [hidden email]
Subject: Re: Dispatch Router throughput

Hi,

I have a setup on my laptop (Lenovo W541, core i7 @2.8GHz, 16Gb) and I can run:
 1. single router 0.8.x; 4 worker threads
 2. a qpid-proton C++ simple-send sender; message body is string "abc"
 3. a amqpdotnet client running under mono, initial-credit 250

Sending to address { prefix: q1-multicast, distribution: multicast } : 40,000 m/sec
Sending to address { prefix: q1-balanced,  distribution: balanced  } : 61,000 m/sec
Sending to address { prefix: q1-closest,   distribution: closest   } : 61,000 m/sec

The setup gets *relative* performance numbers while I fiddle with the code.

HTH,
Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, July 13, 2017 10:20:09 AM
> Subject: Dispatch Router throughput
>
> Hi,
>
> we are currently doing some baseline throughput testing with Dispatch Router
> 0.8.0.
> In the course of doing so, we wondered what number of messages we should be
> able to expect being processed by a single Dispatch Router instance in its
> default configuration, i.e. link capacity 250, 4 worker threads, running on
> a core i7 @2.2GHz.
>
> Let's say we have a single sender, sending pre-settled messages with a
> payload of 20 bytes and a single receiver for the messages.
>
> If all is correctly setup, what number of messages could we expect going
> through Dispatch Router? I am merely interested in an order of magnitude.
> Are we talkinng about 1.000s, 10.000s or 100.000s per second?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Gordon Sim
On 14/07/17 09:07, Hudalla Kai (INST/ECS4) wrote:
> Sadly, though, it doesn't at all match what we are experiencing using
> a vertx-proton based Java sender and consumer where we currently seem
> to not get above 2500 m/sec. I hope that either our test setup is
> completely wrong or that our usage of vertx-proton is erroneous.
That's an order of magnitude off what you should be able to get. How
much credit is your receiver issuing?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
We have been experimenting with different approaches:

1) Using a prefetch of 50
2) Using a prefetch of 1000
3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially

Interestingly, throughput seems to actually go down the more credit we issue, i.e. option 1) yields the best result ...

vertx-proton seems to replenish the sender (Dispatch Router in this case) with one credit each time a message is processed at the cosumer side when using prefetch. Do you consider this to be a problem, i.e. wouldn't it be more efficient to replenish the sender with, say, 200 more credits en block once in a while?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Gordon Sim <[hidden email]>
Sent: Friday, July 14, 2017 10:14
To: [hidden email]
Subject: Re: Dispatch Router throughput

On 14/07/17 09:07, Hudalla Kai (INST/ECS4) wrote:
> Sadly, though, it doesn't at all match what we are experiencing using
> a vertx-proton based Java sender and consumer where we currently seem
> to not get above 2500 m/sec. I hope that either our test setup is
> completely wrong or that our usage of vertx-proton is erroneous.
That's an order of magnitude off what you should be able to get. How
much credit is your receiver issuing?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Gordon Sim
On 14/07/17 09:47, Hudalla Kai (INST/ECS4) wrote:
> We have been experimenting with different approaches:
>
> 1) Using a prefetch of 50
> 2) Using a prefetch of 1000
> 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially
>
> Interestingly, throughput seems to actually go down the more credit we issue, i.e. option 1) yields the best result ...
>
> vertx-proton seems to replenish the sender (Dispatch Router in this case) with one credit each time a message is processed at the cosumer side when using prefetch. Do you consider this to be a problem, i.e. wouldn't it be more efficient to replenish the sender with, say, 200 more credits en block once in a while?

Yes, probably it would, but that wouldn't account for the perf you are
seeing. There must be some other factor. I assume you are sending as
much as you have credit for at any point? You don't have full trace
logging on the router?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Not yet, but I can certainly turn it on. Can you recommend log settings that will reveal the necessary information?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Gordon Sim <[hidden email]>
Sent: Friday, July 14, 2017 14:11
To: [hidden email]
Subject: Re: Dispatch Router throughput

On 14/07/17 09:47, Hudalla Kai (INST/ECS4) wrote:
> We have been experimenting with different approaches:
>
> 1) Using a prefetch of 50
> 2) Using a prefetch of 1000
> 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits initially
>
> Interestingly, throughput seems to actually go down the more credit we issue, i.e. option 1) yields the best result ...
>
> vertx-proton seems to replenish the sender (Dispatch Router in this case) with one credit each time a message is processed at the cosumer side when using prefetch. Do you consider this to be a problem, i.e. wouldn't it be more efficient to replenish the sender with, say, 200 more credits en block once in a while?

Yes, probably it would, but that wouldn't account for the perf you are
seeing. There must be some other factor. I assume you are sending as
much as you have credit for at any point? You don't have full trace
logging on the router?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Gordon Sim
On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote:
> Not yet, but I can certainly turn it on.

No! I was checking it was off as the full logging can slow things down a
lot (especially logging to a terminal).

Is your test client available somewhere? I'm a bit puzzled as to what is
going on and perhaps if I run it we can at least figure out whether its
the client or the router env that is causing the issue.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Ganesh Murthy
On Fri, Jul 14, 2017 at 8:43 AM, Gordon Sim <[hidden email]> wrote:

> On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote:
>
>> Not yet, but I can certainly turn it on.
>>
>
> No! I was checking it was off as the full logging can slow things down a
> lot (especially logging to a terminal).
>
> Is your test client available somewhere? I'm a bit puzzled as to what is
> going on and perhaps if I run it we can at least figure out whether its the
> client or the router env that is causing the issue.

Along with the test client, can you also please send your router config
file? Thanks.

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Thanks everybody for your help with this problem. I think that we will first need to isolate the problem further down to the lower layers. Currently, there are too many components involved AFAIC. We will now first create a test client just based on vertx-proton in order to rule out our Hono specific code on top of it.

We will come back with the outcome of this once we have run some tests using the plain client.

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Ganesh Murthy <[hidden email]>
Sent: Friday, July 14, 2017 15:14
To: [hidden email]
Subject: Re: Dispatch Router throughput

On Fri, Jul 14, 2017 at 8:43 AM, Gordon Sim <[hidden email]> wrote:

> On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote:
>
>> Not yet, but I can certainly turn it on.
>>
>
> No! I was checking it was off as the full logging can slow things down a
> lot (especially logging to a terminal).
>
> Is your test client available somewhere? I'm a bit puzzled as to what is
> going on and perhaps if I run it we can at least figure out whether its the
> client or the router env that is causing the issue.

Along with the test client, can you also please send your router config
file? Thanks.

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Ted Ross
When doing throughput benchmarking, I would strongly recommend using
unsettled deliveries.  With pre-settled deliveries, there is no effective
end-to-end flow control.  If there is congestion (senders faster than
receivers), the router will aggressively discard excess pre-settled
deliveries.  If you use unsettled deliveries, the router will be able to
provide smooth end-to-end flow control.

It is my understanding from the benchmarking that we have done that
unsettled deliveries perform as well or better than pre-settled deliveries.

-Ted

On Mon, Jul 17, 2017 at 3:23 AM, Hudalla Kai (INST/ECS4) <
[hidden email]> wrote:

> Thanks everybody for your help with this problem. I think that we will
> first need to isolate the problem further down to the lower layers.
> Currently, there are too many components involved AFAIC. We will now first
> create a test client just based on vertx-proton in order to rule out our
> Hono specific code on top of it.
>
> We will come back with the outcome of this once we have run some tests
> using the plain client.
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Ganesh Murthy <[hidden email]>
> Sent: Friday, July 14, 2017 15:14
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> On Fri, Jul 14, 2017 at 8:43 AM, Gordon Sim <[hidden email]> wrote:
>
> > On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote:
> >
> >> Not yet, but I can certainly turn it on.
> >>
> >
> > No! I was checking it was off as the full logging can slow things down a
> > lot (especially logging to a terminal).
> >
> > Is your test client available somewhere? I'm a bit puzzled as to what is
> > going on and perhaps if I run it we can at least figure out whether its
> the
> > client or the router env that is causing the issue.
>
> Along with the test client, can you also please send your router config
> file? Thanks.
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Hi Ted,

that is interesting to hear. Thanks for the advice/recommendation. We have also started to use unsettled deliveries (AT_LEAST_ONCE in vertx-proton) but still are not able to get more than 2000 - 3000 messages/sec throughput :-( We will strip everything down to the bare minimum and then post our setup, i.e. sender/receiver code and Dispatch Router config.

BTW We are running Dispatch Router by means of the enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any concerns regarding a negative impact this might have on throughput?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Ted Ross <[hidden email]>
Sent: Monday, July 17, 2017 20:16
To: [hidden email]
Subject: Re: Dispatch Router throughput

When doing throughput benchmarking, I would strongly recommend using
unsettled deliveries.  With pre-settled deliveries, there is no effective
end-to-end flow control.  If there is congestion (senders faster than
receivers), the router will aggressively discard excess pre-settled
deliveries.  If you use unsettled deliveries, the router will be able to
provide smooth end-to-end flow control.

It is my understanding from the benchmarking that we have done that
unsettled deliveries perform as well or better than pre-settled deliveries.

-Ted

On Mon, Jul 17, 2017 at 3:23 AM, Hudalla Kai (INST/ECS4) <
[hidden email]> wrote:

> Thanks everybody for your help with this problem. I think that we will
> first need to isolate the problem further down to the lower layers.
> Currently, there are too many components involved AFAIC. We will now first
> create a test client just based on vertx-proton in order to rule out our
> Hono specific code on top of it.
>
> We will come back with the outcome of this once we have run some tests
> using the plain client.
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Ganesh Murthy <[hidden email]>
> Sent: Friday, July 14, 2017 15:14
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> On Fri, Jul 14, 2017 at 8:43 AM, Gordon Sim <[hidden email]> wrote:
>
> > On 14/07/17 13:27, Hudalla Kai (INST/ECS4) wrote:
> >
> >> Not yet, but I can certainly turn it on.
> >>
> >
> > No! I was checking it was off as the full logging can slow things down a
> > lot (especially logging to a terminal).
> >
> > Is your test client available somewhere? I'm a bit puzzled as to what is
> > going on and perhaps if I run it we can at least figure out whether its
> the
> > client or the router env that is causing the issue.
>
> Along with the test client, can you also please send your router config
> file? Thanks.
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Gordon Sim
On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> We are running Dispatch Router by means of the enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any concerns regarding a negative impact this might have on throughput?

Using that image (default config) with qpid-send/qpid-receive from
qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.

Using the vertx-proton option for Justin Ross's quiver benchmark[1]
against that same image I get ~39k msgs/sec.

[1] https://github.com/ssorj/quiver/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Hi,

I think we have narrowed it down.

Running the quiver test as suggested by Gordon (thanks for that :-)) and using the Dispatch Router config below, we get around 30000 msg/sec if we set "enableVhostPolicy" to false and around 2500 msgs/sec when we set it to "true".

[
  ["router", {
    "id": "Hono.Example.Router",
    "mode": "standalone",
    "workerThreads": 4
  }],

  ["listener", {
    "host": "0.0.0.0",
    "port": 5672,
    "authenticatePeer": false,
    "linkCapacity": 1000
  }],

  ["policy", {
    "enableVhostPolicy": false,
    "defaultVhost": "hono"
  }],

  ["vhost", {
      "id": "hono",
      "allowUnknownUser": true,
      "groups": {
        "$default": {
          "remoteHosts": "*",
          "sources": "*",
          "targets": "*"
        }
      }
  }],

  ["log", {
    "module": "DEFAULT",
    "enable": "info+"
  }]
]

We are running the test against the enmasseproject/qdrouterd-base:0.8.0-1 Docker image.
Is this the expected behavior?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Gordon Sim <[hidden email]>
Sent: Tuesday, July 18, 2017 14:05
To: [hidden email]
Subject: Re: Dispatch Router throughput

On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> We are running Dispatch Router by means of the enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any concerns regarding a negative impact this might have on throughput?

Using that image (default config) with qpid-send/qpid-receive from
qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.

Using the vertx-proton option for Justin Ross's quiver benchmark[1]
against that same image I get ~39k msgs/sec.

[1] https://github.com/ssorj/quiver/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Chuck Rolke
In the hono vhost policy section try adding:

    "allowUserIdProxy": true

If the user id proxy setting is false then the router must parse every
message through to the user-id field of the message properties. Then
verify that the user has no name in the message user-id or the
same name that was used when the connection was created.
Allowing the user id proxy bypasses the per-message parsing and checking.

The down side of setting the user id proxy to true is it allows
the user to launch messages into the system with any user-id.

Per-message checks are avoided altogether when the messages arrive
over a 'link routed' path. That should give you even better numbers.

-Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 18, 2017 11:21:40 AM
> Subject: Re: Dispatch Router throughput
>
> Hi,
>
> I think we have narrowed it down.
>
> Running the quiver test as suggested by Gordon (thanks for that :-)) and
> using the Dispatch Router config below, we get around 30000 msg/sec if we
> set "enableVhostPolicy" to false and around 2500 msgs/sec when we set it to
> "true".
>
> [
>   ["router", {
>     "id": "Hono.Example.Router",
>     "mode": "standalone",
>     "workerThreads": 4
>   }],
>
>   ["listener", {
>     "host": "0.0.0.0",
>     "port": 5672,
>     "authenticatePeer": false,
>     "linkCapacity": 1000
>   }],
>
>   ["policy", {
>     "enableVhostPolicy": false,
>     "defaultVhost": "hono"
>   }],
>
>   ["vhost", {
>       "id": "hono",
>       "allowUnknownUser": true,
>       "groups": {
>         "$default": {
>           "remoteHosts": "*",
>           "sources": "*",
>           "targets": "*"
>         }
>       }
>   }],
>
>   ["log", {
>     "module": "DEFAULT",
>     "enable": "info+"
>   }]
> ]
>
> We are running the test against the enmasseproject/qdrouterd-base:0.8.0-1
> Docker image.
> Is this the expected behavior?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Gordon Sim <[hidden email]>
> Sent: Tuesday, July 18, 2017 14:05
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> > We are running Dispatch Router by means of the
> > enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any
> > concerns regarding a negative impact this might have on throughput?
>
> Using that image (default config) with qpid-send/qpid-receive from
> qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.
>
> Using the vertx-proton option for Justin Ross's quiver benchmark[1]
> against that same image I get ~39k msgs/sec.
>
> [1] https://github.com/ssorj/quiver/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Hi Chuck,

thanks for the advice. Sadly, though, this doesn't seem to have any (positive) impact, i.e. using the config below, we still only get max 2500 msg/sec throughput.

[
  ["router", {
    "id": "Hono.Example.Router",
    "mode": "standalone",
    "workerThreads": 4
  }],

  ["listener", {
    "host": "0.0.0.0",
    "port": 5672,
    "authenticatePeer": "no",
    "linkCapacity": 1000
  }],

  ["address", {
    "prefix": "telemetry/",
    "distribution": "balanced"
  }],

  ["policy", {
    "maxConnections": 1000,
    "enableVhostPolicy": true
  }],

  ["vhost", {
      "id": "$default",
      "maxConnections": 100,
      "allowUnknownUser": true,
      "groups": {
        "$default": {
          "remoteHosts": "*",
          "maxSessions": 500,
          "maxMessageSize": 204800,
          "allowUserIdProxy": true,
          "sources": "*",
          "targets": "*"
        }
      }
  }],

  ["log", {
    "module": "DEFAULT",
    "enable": "info+"
  }]
]

Any thoughts?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Chuck Rolke <[hidden email]>
Sent: Tuesday, July 18, 2017 20:40
To: [hidden email]
Subject: Re: Dispatch Router throughput

In the hono vhost policy section try adding:

    "allowUserIdProxy": true

If the user id proxy setting is false then the router must parse every
message through to the user-id field of the message properties. Then
verify that the user has no name in the message user-id or the
same name that was used when the connection was created.
Allowing the user id proxy bypasses the per-message parsing and checking.

The down side of setting the user id proxy to true is it allows
the user to launch messages into the system with any user-id.

Per-message checks are avoided altogether when the messages arrive
over a 'link routed' path. That should give you even better numbers.

-Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 18, 2017 11:21:40 AM
> Subject: Re: Dispatch Router throughput
>
> Hi,
>
> I think we have narrowed it down.
>
> Running the quiver test as suggested by Gordon (thanks for that :-)) and
> using the Dispatch Router config below, we get around 30000 msg/sec if we
> set "enableVhostPolicy" to false and around 2500 msgs/sec when we set it to
> "true".
>
> [
>   ["router", {
>     "id": "Hono.Example.Router",
>     "mode": "standalone",
>     "workerThreads": 4
>   }],
>
>   ["listener", {
>     "host": "0.0.0.0",
>     "port": 5672,
>     "authenticatePeer": false,
>     "linkCapacity": 1000
>   }],
>
>   ["policy", {
>     "enableVhostPolicy": false,
>     "defaultVhost": "hono"
>   }],
>
>   ["vhost", {
>       "id": "hono",
>       "allowUnknownUser": true,
>       "groups": {
>         "$default": {
>           "remoteHosts": "*",
>           "sources": "*",
>           "targets": "*"
>         }
>       }
>   }],
>
>   ["log", {
>     "module": "DEFAULT",
>     "enable": "info+"
>   }]
> ]
>
> We are running the test against the enmasseproject/qdrouterd-base:0.8.0-1
> Docker image.
> Is this the expected behavior?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Gordon Sim <[hidden email]>
> Sent: Tuesday, July 18, 2017 14:05
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> > We are running Dispatch Router by means of the
> > enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any
> > concerns regarding a negative impact this might have on throughput?
>
> Using that image (default config) with qpid-send/qpid-receive from
> qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.
>
> Using the vertx-proton option for Justin Ross's quiver benchmark[1]
> against that same image I get ~39k msgs/sec.
>
> [1] https://github.com/ssorj/quiver/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Chuck Rolke
Hi Hudalla,

I spun up your configuration and got the same disappointing throughput
numbers. A network trace reveals that with the policy in place the
session handshake reduces the sender-to-router Incoming-Window to 1.
This means that only one message can be outstanding on the link until
the router returns a disposition that retires it. Then the sender is
free to send the next message. That causes the slowdown.

Adding the configuration lines:

          "maxFrameSize": 16384,
          "maxSessionWindow": 3276800,

sets the session so that it can have 200 messages outstanding. This
restores the performance to the 30,000 msgs/S region.

With no router policy in effect the Incoming-Window is 2147483647.
Essentially the sender can send an unlimited number of frames and
the session window will never be closed.

-Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, July 19, 2017 2:47:25 AM
> Subject: Re: Dispatch Router throughput
>
> Hi Chuck,
>
> thanks for the advice. Sadly, though, this doesn't seem to have any
> (positive) impact, i.e. using the config below, we still only get max 2500
> msg/sec throughput.
>
> [
>   ["router", {
>     "id": "Hono.Example.Router",
>     "mode": "standalone",
>     "workerThreads": 4
>   }],
>
>   ["listener", {
>     "host": "0.0.0.0",
>     "port": 5672,
>     "authenticatePeer": "no",
>     "linkCapacity": 1000
>   }],
>
>   ["address", {
>     "prefix": "telemetry/",
>     "distribution": "balanced"
>   }],
>
>   ["policy", {
>     "maxConnections": 1000,
>     "enableVhostPolicy": true
>   }],
>
>   ["vhost", {
>       "id": "$default",
>       "maxConnections": 100,
>       "allowUnknownUser": true,
>       "groups": {
>         "$default": {
>           "remoteHosts": "*",
>           "maxSessions": 500,
>           "maxMessageSize": 204800,
>           "allowUserIdProxy": true,
>           "sources": "*",
>           "targets": "*"
>         }
>       }
>   }],
>
>   ["log", {
>     "module": "DEFAULT",
>     "enable": "info+"
>   }]
> ]
>
> Any thoughts?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Chuck Rolke <[hidden email]>
> Sent: Tuesday, July 18, 2017 20:40
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> In the hono vhost policy section try adding:
>
>     "allowUserIdProxy": true
>
> If the user id proxy setting is false then the router must parse every
> message through to the user-id field of the message properties. Then
> verify that the user has no name in the message user-id or the
> same name that was used when the connection was created.
> Allowing the user id proxy bypasses the per-message parsing and checking.
>
> The down side of setting the user id proxy to true is it allows
> the user to launch messages into the system with any user-id.
>
> Per-message checks are avoided altogether when the messages arrive
> over a 'link routed' path. That should give you even better numbers.
>
> -Chuck
>
> ----- Original Message -----
> > From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> > To: [hidden email]
> > Sent: Tuesday, July 18, 2017 11:21:40 AM
> > Subject: Re: Dispatch Router throughput
> >
> > Hi,
> >
> > I think we have narrowed it down.
> >
> > Running the quiver test as suggested by Gordon (thanks for that :-)) and
> > using the Dispatch Router config below, we get around 30000 msg/sec if we
> > set "enableVhostPolicy" to false and around 2500 msgs/sec when we set it to
> > "true".
> >
> > [
> >   ["router", {
> >     "id": "Hono.Example.Router",
> >     "mode": "standalone",
> >     "workerThreads": 4
> >   }],
> >
> >   ["listener", {
> >     "host": "0.0.0.0",
> >     "port": 5672,
> >     "authenticatePeer": false,
> >     "linkCapacity": 1000
> >   }],
> >
> >   ["policy", {
> >     "enableVhostPolicy": false,
> >     "defaultVhost": "hono"
> >   }],
> >
> >   ["vhost", {
> >       "id": "hono",
> >       "allowUnknownUser": true,
> >       "groups": {
> >         "$default": {
> >           "remoteHosts": "*",
> >           "sources": "*",
> >           "targets": "*"
> >         }
> >       }
> >   }],
> >
> >   ["log", {
> >     "module": "DEFAULT",
> >     "enable": "info+"
> >   }]
> > ]
> >
> > We are running the test against the enmasseproject/qdrouterd-base:0.8.0-1
> > Docker image.
> > Is this the expected behavior?
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Kai Hudalla
> > Chief Software Architect
> >
> > Bosch Software Innovations GmbH
> > Schöneberger Ufer 89-91
> > 10785 Berlin
> > GERMANY
> > www.bosch-si.com
> >
> > Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> > 148411 B;
> > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> > ________________________________________
> > From: Gordon Sim <[hidden email]>
> > Sent: Tuesday, July 18, 2017 14:05
> > To: [hidden email]
> > Subject: Re: Dispatch Router throughput
> >
> > On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> > > We are running Dispatch Router by means of the
> > > enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any
> > > concerns regarding a negative impact this might have on throughput?
> >
> > Using that image (default config) with qpid-send/qpid-receive from
> > qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.
> >
> > Using the vertx-proton option for Justin Ross's quiver benchmark[1]
> > against that same image I get ~39k msgs/sec.
> >
> > [1] https://github.com/ssorj/quiver/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dispatch Router throughput

Hudalla Kai (INST/ESY1)
Hi Chuck,

thanks for getting to the root cause of this problem. Your proposed changes indeed fixed the problem for us.

Thanks again :-)

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Chuck Rolke <[hidden email]>
Sent: Wednesday, July 19, 2017 16:57
To: [hidden email]
Subject: Re: Dispatch Router throughput

Hi Hudalla,

I spun up your configuration and got the same disappointing throughput
numbers. A network trace reveals that with the policy in place the
session handshake reduces the sender-to-router Incoming-Window to 1.
This means that only one message can be outstanding on the link until
the router returns a disposition that retires it. Then the sender is
free to send the next message. That causes the slowdown.

Adding the configuration lines:

          "maxFrameSize": 16384,
          "maxSessionWindow": 3276800,

sets the session so that it can have 200 messages outstanding. This
restores the performance to the 30,000 msgs/S region.

With no router policy in effect the Incoming-Window is 2147483647.
Essentially the sender can send an unlimited number of frames and
the session window will never be closed.

-Chuck

----- Original Message -----

> From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, July 19, 2017 2:47:25 AM
> Subject: Re: Dispatch Router throughput
>
> Hi Chuck,
>
> thanks for the advice. Sadly, though, this doesn't seem to have any
> (positive) impact, i.e. using the config below, we still only get max 2500
> msg/sec throughput.
>
> [
>   ["router", {
>     "id": "Hono.Example.Router",
>     "mode": "standalone",
>     "workerThreads": 4
>   }],
>
>   ["listener", {
>     "host": "0.0.0.0",
>     "port": 5672,
>     "authenticatePeer": "no",
>     "linkCapacity": 1000
>   }],
>
>   ["address", {
>     "prefix": "telemetry/",
>     "distribution": "balanced"
>   }],
>
>   ["policy", {
>     "maxConnections": 1000,
>     "enableVhostPolicy": true
>   }],
>
>   ["vhost", {
>       "id": "$default",
>       "maxConnections": 100,
>       "allowUnknownUser": true,
>       "groups": {
>         "$default": {
>           "remoteHosts": "*",
>           "maxSessions": 500,
>           "maxMessageSize": 204800,
>           "allowUserIdProxy": true,
>           "sources": "*",
>           "targets": "*"
>         }
>       }
>   }],
>
>   ["log", {
>     "module": "DEFAULT",
>     "enable": "info+"
>   }]
> ]
>
> Any thoughts?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ________________________________________
> From: Chuck Rolke <[hidden email]>
> Sent: Tuesday, July 18, 2017 20:40
> To: [hidden email]
> Subject: Re: Dispatch Router throughput
>
> In the hono vhost policy section try adding:
>
>     "allowUserIdProxy": true
>
> If the user id proxy setting is false then the router must parse every
> message through to the user-id field of the message properties. Then
> verify that the user has no name in the message user-id or the
> same name that was used when the connection was created.
> Allowing the user id proxy bypasses the per-message parsing and checking.
>
> The down side of setting the user id proxy to true is it allows
> the user to launch messages into the system with any user-id.
>
> Per-message checks are avoided altogether when the messages arrive
> over a 'link routed' path. That should give you even better numbers.
>
> -Chuck
>
> ----- Original Message -----
> > From: "Hudalla Kai (INST/ECS4)" <[hidden email]>
> > To: [hidden email]
> > Sent: Tuesday, July 18, 2017 11:21:40 AM
> > Subject: Re: Dispatch Router throughput
> >
> > Hi,
> >
> > I think we have narrowed it down.
> >
> > Running the quiver test as suggested by Gordon (thanks for that :-)) and
> > using the Dispatch Router config below, we get around 30000 msg/sec if we
> > set "enableVhostPolicy" to false and around 2500 msgs/sec when we set it to
> > "true".
> >
> > [
> >   ["router", {
> >     "id": "Hono.Example.Router",
> >     "mode": "standalone",
> >     "workerThreads": 4
> >   }],
> >
> >   ["listener", {
> >     "host": "0.0.0.0",
> >     "port": 5672,
> >     "authenticatePeer": false,
> >     "linkCapacity": 1000
> >   }],
> >
> >   ["policy", {
> >     "enableVhostPolicy": false,
> >     "defaultVhost": "hono"
> >   }],
> >
> >   ["vhost", {
> >       "id": "hono",
> >       "allowUnknownUser": true,
> >       "groups": {
> >         "$default": {
> >           "remoteHosts": "*",
> >           "sources": "*",
> >           "targets": "*"
> >         }
> >       }
> >   }],
> >
> >   ["log", {
> >     "module": "DEFAULT",
> >     "enable": "info+"
> >   }]
> > ]
> >
> > We are running the test against the enmasseproject/qdrouterd-base:0.8.0-1
> > Docker image.
> > Is this the expected behavior?
> >
> > Mit freundlichen Grüßen / Best regards
> >
> > Kai Hudalla
> > Chief Software Architect
> >
> > Bosch Software Innovations GmbH
> > Schöneberger Ufer 89-91
> > 10785 Berlin
> > GERMANY
> > www.bosch-si.com
> >
> > Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> > 148411 B;
> > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
> >
> > ________________________________________
> > From: Gordon Sim <[hidden email]>
> > Sent: Tuesday, July 18, 2017 14:05
> > To: [hidden email]
> > Subject: Re: Dispatch Router throughput
> >
> > On 18/07/17 11:53, Hudalla Kai (INST/ECS4) wrote:
> > > We are running Dispatch Router by means of the
> > > enmasseproject/qdrouterd-base:0.8.0-1 Docker image. Do you have any
> > > concerns regarding a negative impact this might have on throughput?
> >
> > Using that image (default config) with qpid-send/qpid-receive from
> > qpid::messaging, I see >90k msgs/sec, so I don't think it is the image.
> >
> > Using the vertx-proton option for Justin Ross's quiver benchmark[1]
> > against that same image I get ~39k msgs/sec.
> >
> > [1] https://github.com/ssorj/quiver/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...