Hey all.

I've spent some time looking into HAProxy (1.5-dev21) + TLS performance and
stumbled across a few areas where I think we could make some improvements.
In particular I'm interested in time to first byte, as that's a critical
piece for interactive traffic: time to first paint in browsers, time to
first frame for video, etc.

-----

(1) Certificates that exceed 4KB require an extra RTT even with IW10: HA
ships the first 4KB then pauses and waits for client ACK before proceeding
to send remainder of the certificate. At a minimum, this results in an
extra handshake RTT. You can see this in action here:

WPT run: 
*http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/
<http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2/details/>*

tcpdump:
http://www.webpagetest.org/result/140116_VW_3bd95a5cfb7e667498ef13b59639b9bf/2.cap


I believe this is the same exact issue as fixed in nginx here:
https://github.com/nginx/nginx/commit/e52bddaaa90e64b2291f6e58ef1a2cff71604f6a#diff-0584d16332cf0d6dd9adb990a3c76a0cR539

-----

(2) HA allows you to tune max_record_size - yay. That said, using a static
value 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:

http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html
http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html

Would love to hear any thoughts on this. The advantage of above strategy is
that it can give you good performance out-of-the-box and without
sacrificing performance for different kinds of traffic (which is especially
relevant for a proxy...).

Ilya

Reply via email to