On Sat, 2008-03-22 at 20:14 +1300, Amos Jeffries wrote:
> > http://www.mail-archive.com/squid-users@squid-cache.org/msg52509.html
>
> Hmm, not sure exactly what Adrian as planned there, beyond changing the
> underlying malloc/calloc system of squid to something else.
> Added it to the 'undocumented features wishlist' anyway.
In Squid-2 the function copying data from cache_mem is doing a linear
search on each copy from the first mem_node of the object, causing
exponential growth in CPU usage for TCP_MEM_HIT processing with the size
of the cached object.
Squid-3 is different and uses a splay tree for the memory nodes of the
object, and should behave a lot better in this regard.
> > - A better mechanism (B-tree maybe?) for storing cache contents such
> > that cached object URIs can be quickly searched via path or regex for
> > reporting/purging purposes.
>
> We'd have to find a tree that is faster than or as fast as a hash over a
> very large dataset. Otherwise its not worth it to justify an overall
> performance degradation for one or two relatively minor occurances.
The grade of this varies a lot depending on the installation. For
reverse proxy installations selective purging of the cache is very
important.
However, there is other approaches which give the same end result
independently of the store. For example the purge list & generation
counter used by Varnish.
Regards
Henrik
Received on Sat Mar 22 2008 - 15:44:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Apr 01 2008 - 13:00:05 MDT