Re: [squid-users] Squid WCCP and filters rules

On 31/03/11 03:04, gael therond wrote:
>
> The way the "cache" access control is currently implemented in Squid
> it does not play nice for reply-based non-caching. That needs to be
> fixed, but there are other storage and handling problems holding us up.
>
> For now the refresh_pattern can be used to discard non-cacheables
> based on URL regex patterns. Sadly *after* they are already on disk.
> Just set the three time parameters to "0 0% 0" with a lot of the
> override-* options.
>
> You could also try setting a maximum object size on disk cached
> objects, flv/swf videos tend to be 2MB-50MB.
>
> FWIW: You have not actually said it but I get the impression you are
> struggling with speed problems handling the videos flowing through,
> yes? All of the Squid-3.x have shown slowdowns whether caching was
> enabled or not.
>
> Amos
>
>
> HI Amos,
>
> Well, globally, I think I'll just made a file which will contain a list
> of dstdomain to deny in cache.
> Bind with refresh_pattern condition, this should be great.
>
> About the last point:
>
> Nop, I'm not facing any slowdown on my squid.
> The respond time to download the Youtube's video is quite close from the
> original total time which is needed when you made download without squid.
>
> For your information, my squid is currently set like that:
>
> http://pastebin.com/1HjANua8
>
> Just let me know if you saw something wrong ;)
>
> Currently our squid is quite well working.

Sure:
   acl streaming_media dstdomain *.youtube.com

dstdomain treats "*" as an exact character. This ACL is not working.
Which means youtube stuff *is* being cached currently.
Given that it appears to be working well right now you may want to drop
the youtube stuff. See if it works better with that dstdomain written:
   acl streaming_media dstdomain .youtube.com .googlevideo.com
   acl streaming_media dstdomain .video.google.com

(these are the youtube domain names I know of)

Also, putting your security protection rules LAST means they have no effect.

  http_access deny !Safe_Ports
  http_access deny CONNECT !SSL_Ports
  http_access deny all

  ... Internal clients have unlimited open-proxy access to anywhere for
anything.
  Move those Safe_Ports and CONNECT rules up above the general network
allow, preferably to the top of the http_access list.

cache_store_log is usually not needed, you can probably remove that
entry from the config file and save a fair chunk of disk IO.

Using "http_port 3128 transparent" I realy hope you block external
access to that port:
   iptables -t mangle -A INPUT -p tcp --dport 3128 -j DROP

(or similar for other firewalls. The port ONLY needs to be used
internally by the NAT module and Squid).

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5