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