[
https://issues.apache.org/jira/browse/TS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174525#comment-14174525
]
Brian Geffon edited comment on TS-2503 at 10/17/14 12:25 AM:
-------------------------------------------------------------
{code}
+ if (l > SSL_MAX_TLS_RECORD_SIZE) {
+ l -= (l % SSL_MAX_TLS_RECORD_SIZE);
+ }
{code}
Doesn't make sense. The code as implemented will force the flush to be a
multiple of SSL_MAX_TLS_RECORD_SIZE, which shouldn't be the case, otherwise
these variable names are incredibly confusing. As [~bcall] suggests you should
just do:
{code} if (l > SSL_MAX_TLS_RECORD_SIZE) l = SSL_MAX_TLS_RECORD_SIZE; {code}
Other than that I think this looks good.
was (Author: briang):
{{code}}
+ if (l > SSL_MAX_TLS_RECORD_SIZE) {
+ l -= (l % SSL_MAX_TLS_RECORD_SIZE);
+ }
{{code}}
Doesn't make sense. The code as implemented will force the flush to be a
multiple of SSL_MAX_TLS_RECORD_SIZE, which shouldn't be the case, otherwise
these variable names are incredibly confusing. As [~bcall] suggests you should
just do:
{{code}} if (l > SSL_MAX_TLS_RECORD_SIZE) l = SSL_MAX_TLS_RECORD_SIZE; {{code}}
Other than that I think this looks good.
> dynamic TLS record size tuning
> ------------------------------
>
> Key: TS-2503
> URL: https://issues.apache.org/jira/browse/TS-2503
> Project: Traffic Server
> Issue Type: Improvement
> Components: Performance, SSL
> Reporter: James Peach
> Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
> Attachments: TS-2503.diff
>
>
> From [~igrigorik] in TS-2365:
> {quote}
> FWIW, I think you may be interested in this discussion:
> - http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html
> - http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html
> In a nutshell, static record size introduces an inherent tradeoff between
> latency and throughput -- smaller records are good for latency, but hurt
> server throughput by adding bytes and CPU overhead. It would be great if we
> could implement a smarter strategy in ATS. The extra benefit is that it's one
> less knob to tune: the out-of-the-box experience would be better optimized
> for all ATS users, regardless of mix/type of traffic being proxies.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
