[jira] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096475#comment-14096475 ] portl4t commented on TS-1381: - How many bytes do you send in the server intercept ? I use server intercept in combo plugin under our product environment. 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)
[jira] [Commented] (TS-1381) Performance of server intercept without Content-Length is poor
[ https://issues.apache.org/jira/browse/TS-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648587#comment-13648587 ] Leif Hedstrom commented on TS-1381: --- Note that is probably a general case for all transforms too, who also depend on the chunked transform. 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 Reporter: Leif Hedstrom Fix For: 3.5.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
