[squid-dev] RFC: cacheMatchAcl

Alex Rousskov rousskov at measurement-factory.com
Sat Apr 4 15:10:51 UTC 2020


On 4/4/20 2:49 AM, Francesco Chemolli wrote:

> I’m mostly done in a PR replacing the dlink with a std::list but without
> changing the overall design. It does kill a few tens of lines of code
> and is clearer to read tho.

Please note that std::list is usually a lot more expensive than dlink
(i.e., an invasive list) as far as performance is concerned because
std::list does one extra memory allocation for every list element. In
performance-sensitive cases, we should not replace dlink with std::list.


HTH,

Alex.


> On Sat, 4 Apr 2020 at 07:41, Amos Jeffries wrote:
> 
>     On 4/04/20 3:34 am, Alex Rousskov wrote:
>     > On 4/3/20 7:25 AM, Francesco Chemolli wrote:
>     >
>     >>   I'm looking at places where to improve things a bit, and I stumbled
>     >> across cacheMatchAcl . It tries hard to be generic, but it is
>     only ever
>     >> used in ACLProxyAuth::matchProxyAuth . Would it make sense to
>     just have
>     >> a specialised cache for proxyauth?
>     >
>     > I wonder whether proxy_auth is special in this context:
>     >
>     > 1. Is proxy_auth cache radically different from other ACL caches
>     such as
>     > external ACL cache? Or did we just not bother unifying the code
>     > supporting these two caches?
>     >
> 
>     Pretty much yes, we have not done the legwork. Almost every component in
>     Squid which deals with externally provided state has some form of ad-hoc
>     cache. If we are lucky the use a hash or dlink. One at least uses splay
>     (ouch).
> 
> 
>     One of my background projects in the effort to empty the PR queue this
>     year is to implement a proper CLP Map - specifically for PR 30 instead
>     of the LruMap disagreement blocking it. That would be a good container
>     to use for all these small state data caches all over Squid - keyed
>     access with a dual TTL and LFU (fading) removal mechanism.
> 
>     If this ACL cache is not causing issues already we can wait until that
>     gets submitted for review.
> 
> 
>     > 2. Do some other ACLs cache nothing just because we did not have
>     enough
>     > time to add the corresponding caching support? Or do proxy_auth and
>     > external ACL poses some unique properties that no other ACL
>     already has
>     > or likely to have in the foreseeable future?
> 
>     The only thing special is that cache they use is exclusively accessed by
>     them.
> 
>     IDENT, ASN, DNS based ACLs also use caches. But those are a bit detached
>     from the ACL code itself (eg fqdncache) since other code sometimes
>     accesses the cache directly for other uses.
> 
> 
>     Amos
>     _______________________________________________
>     squid-dev mailing list
>     squid-dev at lists.squid-cache.org <mailto:squid-dev at lists.squid-cache.org>
>     http://lists.squid-cache.org/listinfo/squid-dev
> 
> -- 
> @mobile
> 
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
> 



More information about the squid-dev mailing list