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)" <[email protected]>
> To: [email protected]
> 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 <[email protected]>
> Sent: Tuesday, July 18, 2017 20:40
> To: [email protected]
> 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)" <[email protected]>
> > To: [email protected]
> > 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 <[email protected]>
> > Sent: Tuesday, July 18, 2017 14:05
> > To: [email protected]
> > 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
> ---------------------------------------------------------------------
> 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]
