Hi Ilya! On Thu, Jan 16, 2014 at 02:35:42PM -0800, Ilya Grigorik wrote: > 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
Useful stuff, indeed with the larger certs these days, maybe we should try to improve things. > ----- > > (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...). I think we have an option here : haproxy already performs permanent observation of what the traffic looks like (streaming or interactive traffic). It uses this to decide to enable splicing or not. But it should be usable as well for SSL. The principle is quite simple : it counts the number of consecutive times it sees full buffer reads and writes to determine that it's forwarding a streaming content. Thus I think we could use that information to decide to enlarge the SSL buffers. I have no idea how these buffers are enlarged nor how much it costs to do that operation in the middle of traffic, but this is probably something we could experiment with. I'll discuss this with Emeric who knows SSL much better than me. Thanks, Willy
