[
https://issues.apache.org/jira/browse/TS-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874141#comment-13874141
]
Ilya Grigorik commented on TS-2365:
-----------------------------------
James, Wei, great work! Happy to see this land in ATS.
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 proxied.
> Configure max TLS record size
> -----------------------------
>
> Key: TS-2365
> URL: https://issues.apache.org/jira/browse/TS-2365
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, SSL
> Reporter: Wei Sun
> Assignee: James Peach
> Labels: A
> Fix For: 4.2.0
>
> Attachments: TS-2365.diff, ssl_maxrecordsize.diff,
> ssl_maxrecordsize2.diff
>
>
> The client can decipher the data only once it has received a full record over
> SSL. The record size can have significant impact on the page load time
> performance of the application. No limitation on record size means that
> clients might have to download up to 16KB of data before starting to process
> them, whereas very small records incur a larger overhead due to record
> framing. The suggestion is to configure the TLS record size to fit into a
> single TCP segment, this can improve page load times on browsers located over
> high latency or low bandwidth networks.
> ref:
> http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
