> Better yet, implement a wsus server, let it bypass caching and gpo your > users to update from that. That way you can get away from having ms > updates dictate caching options that result in problems with streaming. > You are of course making a few very fatal assumptions: 1) that every service provider with this issue can afford to run a dedicated Windows server machine for this purpose. 2) that they want to. (I for one marvel that people are still willing to run MS windows on ANY server.) 3) that they have Enterprise level of control over where their clients machines get WU from. Hint: Tier 0-3 ISP have _zero_ control over client machine settings. Amos > ________________________________ > > From: Brett Glass [mailto:squid-users@xxxxxxxxxxxxxx] > Sent: Sun 3/1/2009 8:02 AM > To: Amos Jeffries; Brett Glass > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Streaming is killing Squid cache > > > > At 09:47 PM 2/28/2009, Amos Jeffries wrote: > > >>Leaving min at -1, and max at something large (10-50MB?) >> >>Should abort the streams when they reach the max value, You'll have to >> set the max to something reasonably higher than the WU cab size. >>Service Packs may cause issues since they are >100MB each, but are >> infrequent enough to use a spider and cause caching if need be. > > We've actually seen Microsoft updates as big as 800 MB. > > Of course, this is a good argument for turning this setting into something > that's controlled by an ACL, so one could say, "Cache everything from > Microsoft, but not from these streaming providers." Hmm, thinking about this some more... Maybe your fix is to "cache deny X" where X is an ACL defining the streaming sources. The abort logics apparently seem to only hold links open if they are considered cacheable (due to headers and non-denial in Squid). Or perhapse you are hitting the one rare case where "half_closed_clients on" is needed for now to make the abort kick in. Amos
