You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "michael goulish (JIRA)" <ji...@apache.org> on 2014/07/21 21:46:42 UTC

[jira] [Created] (QPID-5910) Throughput regression relative to 0.14

michael goulish created QPID-5910:
-------------------------------------

             Summary: Throughput regression relative to 0.14
                 Key: QPID-5910
                 URL: https://issues.apache.org/jira/browse/QPID-5910
             Project: Qpid
          Issue Type: Bug
    Affects Versions: 0.22
            Reporter: michael goulish
            Assignee: michael goulish
             Fix For: 0.29


If you use qpid-latency-test, hold message size constant, and gradually increase the sending rate (in several tests) you will sooner or later reach a point at which the messaging system's ability to handle throughput saturates.  When that happens, latency will go sky-high.  (I have producer flow-control turned off to be able to compare vs. older code.)

The latest code reaches throughput saturation significantly earlier than older code.  (i.e. at a lower sending rate.)

Also, using 'perf' to help analyze the code, recent code is executing significantly fewer instructions per second than older code.

This probably indicates that come parts of the code are spending too much time *while a lock is held* -- thus preventing other threads from fulfilling their destiny, and having an effect on overall throughput.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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