Hi Ilya, On Tue, Feb 11, 2014 at 03:54:15PM -0800, Ilya Grigorik wrote: > Hey Willy. This is great work, thanks! > > On Sat, Feb 8, 2014 at 11:49 PM, Willy Tarreau <w...@1wt.eu> wrote: > > > > The observations and analysis are interesting, and the choice of solutions > > is not easy. I think that relying on a pause only is dangerous because > > there > > are generally a number of losses when delivering to clients, causing pauses > > during the transfers, and we wouldn't want to reset the window in this > > case, > > TCP congestion control already handles this. > > > > Right, that makes sense. > > I reran the same test page against SPDY3.1 and HTTP backends: > > SPDY/3.1 > - > http://www.webpagetest.org/result/140211_KF_2257217df0d1fe65353b8e8aa415de9b/3/details/ > - http://cloudshark.org/captures/c8eab73137e5?filter=tcp.stream%3D%3D1 > -- packet #271: new request after 1.2s idle timeout > record size is reset > and then ramps to 16K > -- packet #605: new request after 2.5s+ idle timeout > record size is reset
Indeed, the difference is visible in the capture! It makes me feel strange to see haproxy emit small packets in the middle of a stream in TCP mode :-) > HTTP/1.1 > - > http://www.webpagetest.org/result/140211_DF_df85fe6c3e91c96bd38e6c8d1df77ceb/4/details/(uses > 2 TCP connections) > -- http://cloudshark.org/captures/b17452deed52?filter=tcp.stream%3D%3D5 > --- transfers three objects with 1s+ idle timeouts, and record size is > reset and ramps in each run > -- http://cloudshark.org/captures/b17452deed52?filter=tcp.stream%3D%3D9 > --- transfers three objects: record size is reset on new request (no idle > timeout - see packet #287), and also after 1s+ timeout. > > The only difference between SPDY and HTTP/1.1 cases here is that HAProxy > "understands" HTTP/1.1 and resets the record size on one of the connections > with back-to-back requests. As we discussed earlier in the thread, I think > this behavior makes sense in HTTP/1.1 land, so that's great! Even better, > with the new logic, the SPDY connection also works as advertised, with > record size resets when buffer is empty + timeout is reached. > > In short, this looks awesome. :) Yes I think so as well :-) > One last set of followup question on configuration and defaults: > - we allow the user to tune buffer sizes - that's great. > - we allow the user to adjust record sizes: assuming above logic is in > place, can we change the default size to start small by default? I'd rather not do it, at least now. The optimal small size will depend on the MSS and most likely on the ciphers. I'd fear that with a default small size, some users would experience a nasty behaviour with something like two small packets and a third almost empty one. When you send that to certain windows hosts, you can be subject to a 200ms pause because even if the last segment contains a PUSH flag. This could cause more questions here on the list. I'd rather document it or post some articles showing the difference in performance based on such settings, just like you do all the time. After all it's a global setting, so it's not hard to set once for all. Maybe if in the long run we see everybody set it to a similar value, we'll finally change the default setting. What I can do however is to add a build setting to force the default value, just like we do with the buffer size. That way you can update your package and deploy an "optimal-by-default" version :-) > - should we expose the timeout as an additional config variable? I think > this is a reasonable knob to have. 1s could be a default value. It's very easy to expose it, I was really not sure about the benefit of making it configurable. I can add it with the current patch. Thank you very much for these well documented tests and for the suggestions! It's really great to be able to improve the user's experience by playing with the internals of what we're transporting! It's so cool that we'll even offer it in our ALOHA appliance :-) Cheers! Willy
