[
https://issues.apache.org/jira/browse/TS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14174547#comment-14174547
]
Sudheer Vinukonda edited comment on TS-2503 at 10/17/14 12:49 AM:
------------------------------------------------------------------
" If I set a config called SSL_MAX_TLS_RECORD_SIZE I would expect that that's
the largest flush I would ever get, not a single byte more and not a multiple
of it. So by allowing flushes on multiples you're not honoring what the user
would expect"
[~briang] -
Hmm, let me give an example.
If the user sets the ssl.max_record =16K, this code would call one SSL_write
with 16K bytes followed by one flush.
If the user sets the ssl.max_record = 33K, this code would call two SSL_writes
(one with 32K bytes followed by a second with 1K bytes) flushing each time.
Ideally, we should call one SSL_write for 33K to honor the user config, but, to
satisfy the record boundary flush, I break it at multiples of 16K (only when
the config setting is greater than 16K).
I do agree that, I am not entirely sure whether openSSL would treat one
SSL_write with 32K vs two SSL_writes with 16K each identically, but, I hoped
there will be some benefit in CPU by calling one SSL_write vs two SSL_writes.
If this is too confusing, and you and [~bcall] both prefer to just always trim
at 16K boundaries, I am fine with that :=)
was (Author: sudheerv):
" If I set a config called SSL_MAX_TLS_RECORD_SIZE I would expect that that's
the largest flush I would ever get, not a single byte more and not a multiple
of it. So by allowing flushes on multiples you're not honoring what the user
would expect"
[~briang] -
Hmm, let me give an example.
If the user sets the ssl.max_record =16K, this code would call one SSL_write
with 16K bytes followed by one flush.
If the user sets the ssl.max_record = 33K, this code would call two SSL_writes
with 32K bytes followed by 1K bytes flushing each time. Ideally, we should call
one SSL_write for 33K to honor the user config, but, to satisfy the record
boundary flush, I break it at multiples of 16K (only when the config setting is
greater than 16K).
I do agree that, I am not entirely sure whether openSSL would treat one
SSL_write with 32K vs two SSL_writes with 16K each identically, but, I hoped
there will be some benefit in CPU by calling one SSL_write vs two SSL_writes.
If this is too confusing, and you and [~bcall] both prefer to just always trim
at 16K boundaries, I am fine with that :=)
> 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)
