On 27/10/10 22:46, Amos Jeffries wrote:
> On Wed, 27 Oct 2010 17:40:39 +0100, Alex Crow<alex_at_nanogherkin.com>
> wrote:
>> Hello devs,
>>
>> I sent the below to the list a while ago and did not get a response.
> The plan is certainly to port the needed features from 2.6+ into a 3.x. We
> have client_delay_pools in 3.HEAD already and highly likely to be in the
> next 3.2 beta released.
>
> These 3.x controls are based on IP for more consistent control over total
> bandwidth consumption than per-reply can offer. That does limit the ACLs
> usable to the source and destination IP and port at present. Please try
> 3.2.0.3 when it becomes available and see if it meets your needs.
>
> Amos
Dear Amos,
Apologies for resurrecting this, but as 3.2 nears I was wondering what
might have changed. I think dest port (which is what I would have to
check on) is too limiting, as certainly application/x-fcs uses port
80/443 anyway. Reply mime type really seals the deal for Flash stuff
when you've blocked the RTMP port on your firewall - I think that
limiting on the request size helps but it's not as tight.
We get to cut a lot of bandwidth without impacting anything else, eg
financial stats/market info pages that refresh frequently, java applets
for charting, etc. With the right tuning you get enough for radio
listening but stop people watching football (soccer) or the horses all
day. I have argued that if this is happening then surely there's a
supervision/management issue but in IT you're not allowed to say these
things ;-).
Again I know the purpose of squid isn't really as a filter but delay
pools are great and seem to cause less problems than just dropping
inbound packets with QoS/priority rules. I've done the latter and it
seems to make "legit" bulk traffic very "lumpy", ie varies between a
crawl and the limit on a seemingly random basis (this is using the HTB
stuff from shorewall).
Cheers
Alex
Received on Mon Mar 28 2011 - 17:53:47 MDT
This archive was generated by hypermail 2.2.0 : Tue Mar 29 2011 - 12:00:04 MDT