[jira] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor

["Alan M. Carroll (JIRA)" <ji...@apache.org>]

    [ 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)