[
https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096152#comment-14096152
]
Alan M. Carroll commented on TS-1381:
-------------------------------------
Moved to 6.0.0. I need to revisit the chunking logic anyway. I think one
problem is the flow can accumulate large numbers of small buffers which are
then searched linearly on every chunk write. This quadratic slow down may
account for the performance problem.
IMHO the best approach is to expand and generalize some of the methods I added
for flow control, specifically is_read_avail_at_least(). This is the main
reason chunks lists are scanned, via read_avail(). Rarely does the caller need
to know how much is really available, but really only if there is are at least
N bytes available.
> Performance of server intercept without Content-Length is poor
> --------------------------------------------------------------
>
> Key: TS-1381
> URL: https://issues.apache.org/jira/browse/TS-1381
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP, Performance
> Reporter: Leif Hedstrom
> Assignee: Alan M. Carroll
> Fix For: 6.0.0
>
>
> When using a server intercept plugin, if the plugin is unable (for whatever
> reason) to inject a Content-Length header, we perform chunked encoding on the
> body. This turns out to be pretty slow, I'm seeing at least 5-8x slowdown
> doing this chunking, vs simply setting a CL: header.
> The reason I'm filing this is because for certain server intercept plugins,
> such as an fcgi plugin, this could be bad for performance. I can see that
> there would be some overhead doing the chunking, but 800% seems very steep.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
