Hi Brendan, On Sat, Oct 22, 2016 at 11:39:51AM -0400, Brendan Kearney wrote: > On 10/22/2016 02:08 AM, Willy Tarreau wrote: > > > You're welcome. Please note that the reuse mechanism is not perfect and > > can still be improved. So do not hesitate to report any issue you find, > > we definitely need real-world feedback like this. I cannot promise that > > every issue will be fixed, but at least we need to consider them and see > > what can be done. > > > > Cheers, > > Willy > > > i have http interception in place, using iptables/DNAT to redirect traffic > to haproxy and load balance to 2 squid instances. i was using aggressive > mode http-reuse and it seemed to provide better streaming experience for > roku/sling.
In fact it can be better for all use cases since you save one round trip for most requests by reusing an already connected connection. > after a period of time, the performance degraded and the > experience was worse than original state. buffering, lag and pixelation are > the symptoms. i did not try to use the always mode, and turned http-reuse > off for the interception i am doing. the issue has cleared since. That's a useful report. I don't see a reason here. Hmmm thinking about it there could be one in fact. Maybe you ended up with too many connections on your squids ? But even in that situation, aggressive would still ensure that some of the requests are properly delivered. Another possibility is that some TIME_WAIT connections have been accumulating on the haproxy machine in the direction of the squid servers, because aggressive will still result in closing some connections when they cannot be stolen. What OS are you using ? On Linux it's known to close cleanly (SO_LINGER works well), I don't know for other OSes. Or do you happen to have a firewall between linux and squid which would sometimes catch the reset but with the squid occasionally not getting it ? That's an issue which sometimes affects http-server-close as well. > while interception and transparent proxying seem to be problematic, explicit > proxying and internal http have both seen a marked improvement in > performance. I'm now thinking that transparent could indeed be an issue in this case, because you can sometimes force to close an existing connection from an ip:port source, and suddenly when the client speaks it has to immediately reopen. I'd say that in terms of logging it's a bit ugly to reuse someone else's connection because the requests that come to your squid can pretend to be from client A while in fact client A was the first one to cause the connection to establish and client B is the one sending the next request. Do you use "usesrc client" or "usesrc clientip" ? The former will force the same ip:port to be reused and it can indeed cause some trouble due to the other side not always getting the close in time. If the latter, the source port is dynamically allocated so the ports should rotate. > no scientific collection of data has been done, but page load > times have been noticeably improved. i may move from aggressive to always > for these backends. In my experience, Squid is quite good at keeping connections opened, so yes it might work well without causing trouble to users. Willy
