You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Kim van der Riet (Created) (JIRA)" <ji...@apache.org> on 2011/11/23 18:09:40 UTC
[jira] [Created] (QPID-3644) qpid-perftest on c++ broker shows
large consume rate drops at 64k message size boundaries
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org