On 03/06/11 10:59, E.S. Rosenberg wrote:
Hi,
I set up a authenticating proxy, and based on the username I want to
change properties of the connection.
According to the documentation the proxy_auth type acl is slow because
it relies on external helpers, no my question is is it slow only the
first instance that squid meets it (ie. when REQUIRED and therefor
doing the actual authentication) and does squid after that 'know' the
username making it more or less equally fast to other acls or is every
instance of the proxy_auth acl type slow?
Yes.
Bit of confusing terminology here. Some genius decided to classify ACL
by their worst-case speed.
So we have essentially two groups of ACL those called "fast" and those
called "slow". This has nothing to do with *actual* speed. Just
worst-case speed.
Of course none of us like things being too slow so all the slow group
ACL have little lookup result caches. These can make repeated use be
faster than some of the fast ACL (namely the regexs ones where testing
is hard).
ie:
acl auth_users proxy_auth REQUIRED # this is slow.
acl whitelist_users proxy_auth some_dude someoherdude # is this slow?
Slower than "REQUIRED" when either is tested in isolation.
They both do the same actions, but the second one additionally tests the
requiting username against a list of possible values.
acl special_users proxy_auth really_special_guy # or is this fast
because by now squid already knows the username?
same as acl line 2 above.
Yes. Doing several proxy_auth in sequence, the username cache skips all
the lookup+validate work on the repeats. Doing repeated username tests
is as fast as dstdomain.
Caveat: Once the username cache TTL runs out the backend re-validation
is repeated. So with short TTL you get "random" slowdowns on particular
ACL tests. Of the auth backend now says fail, you can also potentially
get a sudden denial halfway down the list of repeated auth testing ACL.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.8 and 3.1.12.2
