[
https://issues.apache.org/jira/browse/TS-5095?focusedWorklogId=33542&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-33542
]
ASF GitHub Bot logged work on TS-5095:
--------------------------------------
Author: ASF GitHub Bot
Created on: 13/Dec/16 23:47
Start Date: 13/Dec/16 23:47
Worklog Time Spent: 10m
Work Description: GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/1259
TS-5095: IOBufferReader::read_avail adds to CPU utilization
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shinrich/trafficserver ts-5095
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/1259.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1259
----
commit 6018e3bc95eec14b626d3a1069dd82dc9654eac5
Author: Susan Hinrichs <[email protected]>
Date: 2016-12-13T23:46:04Z
TS-5095: IOBufferReader::read_avail adds to CPU utilization
----
Issue Time Tracking
-------------------
Worklog Id: (was: 33542)
Time Spent: 10m
Remaining Estimate: 0h
> IOBufferReader::read_avail adds considerably to CPU utilization
> ---------------------------------------------------------------
>
> Key: TS-5095
> URL: https://issues.apache.org/jira/browse/TS-5095
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When installing a new build of our ATS, we noticed that the CPU utilization
> was higher than a non-upgraded peer in the same pod. Looking at perf top for
> that process we saw that 10-17% of CPU was spent in
> IOBufferReader::read_avail. In the older system, that function didn't show up
> in the top couple screens of perf top.
> I tracked it down to an "ink_assert(read_avail() > 0)" call in
> IOBufferReader::consume. We didn't have the debug asserts compiled in, but
> the parameter arguments are still being executed. Commented out the
> ink_assert call and the CPU utilization went back to normal. We later found
> a similar growth in IOBufferReader::read() due to the use of
> IOBufferReader::read_avail.
> It looks like the issue is compiling with openssl 1.0.2 instead of openssl
> 1.0.1. We have been running against the openssl 1.0.2 library but were still
> compiling against openssl 1.0.1. We recently upgraded our builds to compile
> against the new openssl as well.
> I built a version of the older source against openssl 1.0.2 and it had very
> similar performance to what I was seeing with the newer source.
> Still don't know why compiling against the newer openssl would make such a
> difference. But it is easy enough to rework these use cases to take
> read_avail (which walks the block chain) out of the fast path. This should
> be a good optimization in any case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
