qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-5910) Throughput regression relative to 0.14
Date Tue, 22 Jul 2014 12:36:38 GMT

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

ASF subversion and git services commented on QPID-5910:
-------------------------------------------------------

Commit 1612559 from [~mgoulish] in branch 'qpid/trunk'
[ https://svn.apache.org/r1612559 ]

QPID-5910
The previous way of computing required credit was apparently
pretty slow -- perhaps because it is doing some  unnceessary
copying down in its guts.  (Which theory I did not prove.)
And it was running while a lock was held, which caused a
significant throughput regression (which was reported as an
enormous latency regression.)
The simpler means of calculating credit in this diff removes
most of the problem.

> 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


Mime
View raw message