On 01/20/2013 04:10 AM, Ralf Hildebrandt wrote:
> According to what I found in the FAQ, the "hot object cache" is
> located in RAM, taking an amount of RAM limited by cache_mem.
>
> So, frequently requested objects are stored in this memory area. But
> what is a hot item?
Currently, a "hot object" in Squid terminology is an object cached in
RAM (i.e., memory cache). Nothing more.
In general, Squid tries to keep all cachable objects in RAM, but there
are configuration options that restrict this "greedy" behavior. Besides
configurable size restrictions mentioned on this thread, see
memory_cache_mode in squid.conf.documented for ways to influence memory
cache admission algorithm.
Once the object is in the memory cache, it will be evicted using memory
cache replacement policy. For non-shared memory cache, the policy is
configurable using memory_replacement_policy. For SMP shared memory
cache, the policy is currently not configurable and can be considered
"random".
>> 2c) Current [Rock] implementation uses OS buffers for simplicity.
>> 2c) Makes the theoretical approach to evaluate performance advantages of
>> Rock almost impossible.
That depends on how realistic your theoretical model is, of course.
Besides, to evaluate _advantages_, you have to model the competing
stores as well, and since all of them currently use system buffers, this
is not a Rock-specific complication.
In general, no store will be the best for all environments and for all
evaluation criteria. Thus, any comparison, theoretical or not, has to
account for environment factors and optimization goals.
On 01/21/2013 08:58 PM, Amos Jeffries wrote:
> Rock was built on that 2.7 [COSS] track
> record with a few design fixes for lessons learned since COSS was
> created and SMP support.
I would not phrase it that way because it may create a false impression
that Rock is an improved COSS, which was not the Rock development goal
(and may or may not be true as far as current performance is concerned).
Both Rock and COSS are based on the same subset of disk caching
optimization ideas thrown around some 15 years ago. However, they
interpret some of those ideas differently and each store uses its own
set of unique ideas and techniques.
In practical terms, there is no usable COSS for Squid3, making
apples-to-apples actual performance comparisons impossible.
> Under Rock/COSS requests within a certain time range of each other
> are assigned slots within one memory page/chunk
Unlike COSS, Rock does not use that strategy explicitly (in part because
it forces COSS to constantly re-store popular objects IIRC). The current
replacement model in Large Rock may result in similar side-effects, but
we have not studied them.
On 01/22/2013 09:04 AM, babajaga wrote:
> Could you give any further hints, where to find more design principles of
> Rock(-large) ?
Squid wiki pages are the best source of Rock and Large Rock
documentation currently available:
http://wiki.squid-cache.org/Features/RockStore
http://wiki.squid-cache.org/Features/LargeRockStore
If you have questions about Rock not answered there, please post them
here (and CC me) or, if they are development-centric, to squid-dev. You
may want to start a new thread though :-).
Thank you,
Alex.
Received on Wed Jan 23 2013 - 15:59:21 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 23 2013 - 12:00:05 MST