On Sat, 2008-03-22 at 20:14 +1300, Amos Jeffries wrote: > > http://www.mail-archive.com/squid-users@xxxxxxxxxxxxxxx/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
