On Thu, Feb 6, 2014 at 11:03 PM, Willy Tarreau <w...@1wt.eu> wrote: > > Gotcha, thanks. As a follow up question, is it possible for me to control > > the size of the read buffer? > > Yes, in the global section, you can set : > > - tune.bufsize : size of the buffer > - tune.maxrewrite : reserve at the end of the buffer which is left > untouched when receiving HTTP headers > > So during the headers phase, the buffer is considered full with > (bufsize-maxrewrite) bytes. After that, it's bufsize only. >
Perfect - thanks. > > > So if we're in this situation, this will be enough to reset the > CF_STREAMER > > > flag (2 consecutive incomplete reads). I think it would be worth > testing > > > it. > > > A very simple way to test it in your environment would be to chain two > > > instances, one in TCP mode deciphering, and one in HTTP mode. > > > > > > > That's clever. I think for a realistic test we'd need a SPDY backend > > though, since that's the only way we can actually get the multiplexed > > streams flowing in parallel. > > Yes it would be interesting to know how it behaves. > Ok, I have the following setup: client -> haproxy (npn + tcp proxy) -> spdylay (spdy 3.1 without TLS). http://www.webpagetest.org/result/140208_DM_57a2a0feaf3258b93d7e3ce3c802b278/4/details/- 100ms RTT / 3Mbps down. - tcpdump: http://cloudshark.org/captures/666f2481eafa?filter=tcp.stream%3D%3D1 - Page loads two images > onload event > 1s later loads one image > 0.4s later loads another image > 3.6s later loads last image. All resources are loaded over the same SPDY connection (TLS terminated by HAProxy, and SPDY-sans-tls by spdylay :)), and all assets are static assets. As expected, session starts with 1400 byte records, then gets bumped to ~16K records and continues using 16K records until the end of the entire session -- since all resources here are static resources, there are no gaps between HEADERS and DATA frames and we never hit the case of two incomplete reads... This is somewhat suboptimal, since ideally we'd reset record size when delivering the first image after 1s idle pause following onload, and also when delivering the last image following the 3s+ idle pause. Now, let's imagine that HAProxy "understood" SPDY and had knowledge of the individual streams (instead of running in tcp mode): it seems like we *wouldn't* want the logic of new stream > reset record size to apply for SPDY connections. Reset on new request makes sense in HTTP/1.1 mode since everything is serialized and we're using multiple connections (although even here this strategy can be suboptimal if we have back-to-back requests on same connection and low RTT), but when we have many multiplexed streams with SPDY, this behavior would lead to a lot of unnecessary resets - e.g. multiple streams in flight, record size is at 16K, and new stream is initiated and resets record size for everyone. I'm back to wondering if the incomplete read strategy is the best approach to take here. It seems like it wouldn't work out that well for SPDY / HTTP/2 even if HAProxy understood those protocols... unless there was a lot more smarts added for tracking parallel in-flight streams, etc. Instead, seems like a connection idle timeout strategy would be much simpler and would work uniformly well across HTTP/1, HTTP/2 (and any other protocol for that matter) even without understanding any of them? What do you guys think? Am I overlooking anything? ig
