[squid-users] delay pool not workin
Amos Jeffries
squid3 at treenet.co.nz
Tue Sep 26 23:28:12 UTC 2017
On 23/09/17 03:48, Heiler Bemerguy wrote:
> Amos, talking about delay pools, I have a question: does it work if the
> content being served is on a cache peer?
>
It should, yes. Peers are no different than any other server in terms of
I/O bytes.
The only thing I'm aware of in current Squid is maybe bugs with CONNECT
tunnels. Older Squid the pools were a bit broken - I've not had any
recent feedback about those bugs, some are still open but may have been
fixed as side effects of other changes.
> I think it only "shapes" traffic from a SERVER to squid, right? not from
> a peer cache to squid.. :/
Peer is just a server with some statically configured parameters -
traffic format, routing ACLs, etc.
>
> I'm having problems because we use a huge Microsoft Updates repository
> as a cache peer and whenever a client on a 512kbit/s link (!!!!!!!!!)
> starts his box, all the link is flooded with updates from us to it.
WU .cab files should be cacheable objects. Delay pools do not apply to
HIT traffic, and REFRESH traffic is intentionally *much* smaller in
terms of bytes to the server. So you can end up with delay pool shaping
1-2 KB of Squid<->server data and the client receiving GB sized files.
> htcp_access allow localnet
> acl wu dstdom_regex \.download\.windowsupdate\.com$
Sigh. The above is a complex and CPU intensive way to write:
acl wu dstdomain .download.windowsupdate.com
Rule of thumb: when there is an alternative - avoid regex.
> acl wu-rejects dstdom_regex stats
> acl GET method GET
> cache_peer 10.1.10.10 parent 8081 0 proxy-only no-tproxy no-digest
> no-query no-netdb-exchange name=ms1
> cache_peer_access ms1 allow GET wu !wu-rejects
> cache_peer_access ms1 deny all
> never_direct allow GET wu !wu-rejects
> never_direct deny all
> cache deny wu
> cache allow all
>
> prefer_direct off
>
> acl srcdaico src 10.71.0.0/16
> delay_pools 1
> delay_class 1 3
> delay_access 1 allow srcdaico !dstlocal
I suspect this dstlocal is the reason for the peer not being delayed.
Check that the peer IP is not in any of its ranges.
Amos
More information about the squid-users
mailing list