On 16/03/2016 6:51 a.m., Heiler Bemerguy wrote: > > Hi joe, Eliezer, Amos.. today I saw something different regarding high > bandwidth and caching of windows updates ranged requests.. > > A client begins a windows update, it does a: > HEAD to check size or something, which is ok.. > then a ranged GET, which outputs a TCP_MISS/206, > then the next GET gives a TCP_SWAPFAIL_MISS/206. > Lots of other TCP_MISS/206, then in the end, TCP_MISS_ABORTED/000 > > A big amount of parallel connections are being made because of each > GET.. ok, I know squid can't do much about it.. but then, why the > content does not get cached in the end? > I mean, the way it is, it will happen every day.. are these > "TCP_MISS_ABORTED" really the client aborting the download? I doubt it... > It is. These things happen a lot more often than you might expect. All it takes is Squid not knowing properly when the object is ended, or a brief network outage and it will hang for a while (after finishing) until the client disconnects. > Take a look and see if you can understand: I can. The big question is whether *you* understand what is going on? This log extract shows a nice sequential series of Range requests being fetched and satisfied. Until at the end the server stops providing data and the client disconnects with a ~5min timeout. Bandwidth consumed is presumably the correct amount for those downloads. the log does not record server or total bandwidth consumption, only client delivered payload size. So it naturally does not show many hints about what your "high bandwidth" problem is. Also, you have logged in "human" format. Which makes the time differential math to figure out whether those are sequential or parallel transactions VERY difficult. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
