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

Kinkie wrote:
> On Thu, Aug 13, 2009 at 7:32 PM, Henrik
> Nordstrom<henrik_at_henriknordstrom.net> wrote:
>> tor 2009-08-13 klockan 13:35 +0200 skrev Kinkie:
>>> On Thu, Aug 13, 2009 at 12:38 PM, Henrik
>>> Nordstrom<henrik_at_henriknordstrom.net> wrote:
>>>> squid.conf option for tuning when to keep objects in memory.
>>> +1 for the change :)
>>> (adri pointed out on IRC that it may put more pressure on cache_mem,
>>> so some tweaks may be warranted)
>> Setting it to disk would reduce the pressure significantly imho, and is
>> why I continued the effort into adding a tuning option.
>
> Sure. I see that falling back to the current behaviour is also possible.
> Don't misunderstand me: I believe that this is a great development.
> But as I trust Adri's judgement, I felt it would be niceto mention the
> fact. Of course, it's not possible to know for sure until the change
> is in :)
>
>>> Also, a possible improvement might be to use a fast reply ACL lookup
>>> instead of (or in addition to) the config-wide flag to define what
>>> goes back into cache_mem.
>> Maybe, but with cache_mem being as volatile as it is I did not think it
>> was worth the effort.
>
> Well, I guess that the worst thing that can happen is a bit of
> trashing in cache_mem, which should not be that big a deal anyways,
> unless otherwise proven.

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.

Still: +1 from me.

On the ACL line, I have hier_code from 2.x nearly ported which opens the
source delimiter possibilities somewhat.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18
   Current Beta Squid 3.1.0.13