Re: [MERGE] 1/2: Populate cache_mem on disk hits

On Fri, Aug 14, 2009 at 6:10 AM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
> Henrik Nordstrom wrote:
>>
>> fre 2009-08-14 klockan 11:23 +1200 skrev Amos Jeffries:
>>
>>> cache_mem is where the fastest HITS/sec come from. Trashing it will
>>> impact the very upper req/sec of Squid. As will forcing everything to disk
>>> first. Then again with things going disk->memory (how soon Henrik?) it may
>>> not be noticeable with very hot objects always being from memory.
>>
>> NAME: memory_cache_mode
>> TYPE: memcachemode
>> LOC: Config
>> DEFAULT: always
>> DOC_START
>>        Controls which objects to keep in the memory cache (cache_mem)
>>
>>        always  Keep most recently fetched objects in memory (default)
>>
>>        disk    Only disk cache hits are kept in memory, which means
>>                an object must first be cached on disk and then hit
>>                a second time before cached in memory.
>>
>>        network Only objects fetched from network is kept in memory
>> DOC_END
>>
>>
>> Could easily add a tunable to require more than one hit to bring a disk
>> object back into memory if desired.
>
>
> Hmm, actually thinking further ahead (and getting off topic now that the
> feature is approved 4:nil) ...
>
> Do we want to start planning for when the memory cache settings are all
> options on the one base tag?
>
> ie.  memory_cache <size> <options>
>
> where <options> ::= <mode> <replacement_policy> <max-object-size>
> <min-object-size> ... etc.

Even longer term I believe it would be nice to introduce a
memory-backed cache_dir, and the ability to define a hierarchy of
cache_dirs with the ability to move objects among them, so that
cache_mem would only become a "transit" area..

e.g.
cache_dir type=memcore size=128M level=1 maxsize=4M
cache_dir type=mem size=1G level=2 maxsize=32M
cache_dir type=aufs dir=/ssd1 size=32G level=3 minsize=12K
cache_dir type=aufs dir=/hdd1 size=200G level=4
cache_dir type=aufs dir=/hdd2 size=200G level=4
cache_dir type=aufs dir=/hdd3 size=200G level=4

Where 'memcore' would be in-process and memory-based (think a cross
between ufs and cache_mem), 'mem' would be out-of-process and
memory-based (think a cross between diskd and cache_mem). Object MAY
be shuffled among the various cache_dirs using some logic like:
- hottest objects in a level can be _copied_ to a higher level
- coldest objects in a level are _moved_ to a lower level

(this would be 4.X material anyways)

-- 
    /kinkie