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.
