[squid-users] Large ACL's list, the ways to distribute squid caches, asking pro-users for advice.

Hi there,

There is some problems and I asking for advice for spread squid load and
increase perfomance.

Now we have near 4000 users in our university, and one squid proxy
server running on paravirtualized virtual machine (2 x 1.6Ghz Xeon E5310)

We use Squid Accounting system calling SAcc for traffic accounting. It's
generates squid configuration file and reloads squid when user is
banned. Caching is off and squid uses only for proxying and accounting.

There is NCSA authentication with passwd file for 4000 users, and 4000
ACL's generated in squid configuration file like this:

acl popovasi proxy_auth popovasi
http_access allow popovasi
http_access allow popovasi CONNECT

acl halenko proxy_auth halenko
http_access allow halenko
http_access allow halenko CONNECT

acl mamatovaa proxy_auth mamatovaa
http_access allow mamatovaa
http_access allow mamatovaa CONNECT

etc..

Internet connection is not so wide, only 4Mbps and, as I think, most
hard on server is working with huge ACL lists.

----------
What we need and what we can:

We need to spread squid load for better latency and responce to queries
and turn on caching because of tiny internet channel.

And so we have a couple of servers for new squid proxies.

We can use mysql_auth helper for authentication because of all user
database stored in mysql (but in clear-text, we working on it).

We need some expirience and advices for better ACL management. How we
can use one acl for all authorized users in passwd file? Can we get
perfomance increase using CARP and parent proxy? What the perfomance hit
will be if we will use gnu-regexp instead of built-in?
Maybe we should change all user and traffic accounting management. Can
you advice on dynamic distributed accounting and authentication
solutions based on squid (I called it cache-grid :))?

Now, ask you for your expirience. Thanks for reply. Feel free to give
man and URL's for reading on this thread.

Sorry for my English.

Serg Androsov.
Received on Tue Jan 22 2008 - 00:53:24 MST