qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Ross (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-3644) qpid-perftest on c++ broker shows large consume rate drops at 64k message size boundaries
Date Fri, 26 Sep 2014 14:40:34 GMT

    [ https://issues.apache.org/jira/browse/QPID-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14149227#comment-14149227
] 

Justin Ross commented on QPID-3644:
-----------------------------------

[~kpvdr], this one's pretty old.  Can we close it?

> qpid-perftest on c++ broker shows large consume rate drops at 64k message size boundaries
> -----------------------------------------------------------------------------------------
>
>                 Key: QPID-3644
>                 URL: https://issues.apache.org/jira/browse/QPID-3644
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Broker, C++ Client
>    Affects Versions: 0.15
>            Reporter: Kim van der Riet
>
> Using a 2-machine test connected with 10g private network, with one machine containing
the broker and the other the client, the following was observed:
> Broker machine (20.0.10.43 on the 10g network):
> ./qpidd --auth no
> Client machine:
> ./qpid-perftest -b 20.0.10.43 --count 20000 --size 65400
> (result: consume rate: 5437.45 transfers/sec)
> ./qpid-perftest -b 20.0.10.43 --count 20000 --size 65500
> (result: consume rate: 696.628 transfers/sec)
> which is a massive drop (to 13% of the initial rate) for a relatively small change in
message size of 100 bytes.
> Again, around the 128k boundary:
> ./qpid-perftest -b 20.0.10.43 --count 20000 --size 130900
> (result: consume rate: 546.144 transfers/sec)
> ./qpid-perftest -b 20.0.10.43 --count 20000 --size 131100
> (result: consume rate: 177.607 transfers/sec)
> which compounds the previous consume rate drop.
> Further observations:
> 1. If qpid-perftest is modified to print a single char every 100 consumes, then it can
be observed that performance is not linear, but starts out fast, but slows down as the test
progresses. Near the end of the test, the consume rate starts to rapidly pick up again.
> 2. Looking at broker trace logs, the consumed messages have a 40-byte header. This means
for these tests that the total message sizes are:
> 65400 + 40 = 65440
> 65500 + 40 = 65540
> 130900 + 40 = 130940
> 131100 + 40 = 131140
> which straddle the 64k and 128k size boundaries.
> 3. The drop in performance is not a step function, but as one draws closer to (but still
below) the boundary, the rate starts to rapidly deteriorate. eg 65450 + 40 is below the 64k
boundary, and has a result between the 65400 and 65500 rates. Similarly for 131000 + 40, which
is slightly below the 128k boundary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message