Re: [squid-users] process load

From: Amos Jeffries <squid3@dont-contact.us>
Date: Thu, 6 Dec 2007 12:57:00 +1300 (NZDT)

> Hi,
>
> Adrian though being a newbie I know about that though not perfect :D.
>
> I basically have 2.5 Ghz computer with 512 MB ram. With those number
> of users hunting squid, how many DSTDOMAIN ACL are considered safe.
>
> I know I can check the process load by adding few ACL at a time. But I
> can't complain management each week to replace the CUP or memory.
>
> So I am here for the help. You guys must have hell lot of experience
> to tell me that in rough figures.

No not really a lot. dstdomain can handle a few hundred thousand rules on
a modern fast server. On the 2.6GHz with just 512MB you should see no
problem with a few thousand.
Expect 10,000 acl entries to take less than ~3MB of RAM and 2000-cycles
processing time.

Particularly if you use the per-client-subnet filtering methods Adrian
mentioned (below) to speed things up even further.

Amos

>
> Regards
> Rishav Upadhaya
> Future System Administrator
> Current Support Officer
>
> On 12/5/07, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> Adrian Chadd wrote:
>> > ACLs are evaluated short-circuit. If you have this:
>> >
>> > acl clientA src 1.2.3.0/24
>> > acl clientB src 1.2.4.0/24
>> > acl youtube (expensive regexp)
>> > acl microsoft (expensive regexp)
>> >
>> > http_access deny clientA youtube
>> > http_access deny clientB microsoft
>> >
>> > the http_access lines are evaluated in order from top to bottom, and
>> stop being
>> > evaluated across each http_access line if one of the ACLs fails.
>> >
>> > So the expensive youtube regexp ACL will only be processed by requests
>> from clientA.
>> > Requests from clientB won't ever hit the youtube ACL lookup.
>> >
>> > If you know how to craft ACLs then you can avoid almost all of the
>> penalties.
>> >
>> > Adrian
>>
>> Adrian! stop encouraging the regexp-addicts. :-)
>>
>> We're trying to wean them off the unnecessary use of slow ACL remember?
>> ;)
>>
>> Amos
>>
>
Received on Wed Dec 05 2007 - 16:57:06 MST

This archive was generated by hypermail pre-2.1.9 : Tue Jan 01 2008 - 12:00:01 MST