Amos, > Under Rock/COSS requests within a certain time range of each other are assigned slots within one memory page/chunk - such that a client loading a page causes, with a high probability, the related objects, images, scripts - to be swapped in and ready to served directly from the RAM area slice before they are requested by the client. < Wow, interesting approach; immediately, however, I think about redundant caching of hot objects (hot in respect to different domains, referencing them). Anyway, having a few more similar remarks to your info, this is not the right thread to discuss such questions; unfortunately in the docs I found, http://wiki.squid-cache.org/Features/RockStore#limitations and references within, I did not find this type of info, you just supplied. But some more open questions to me. Could you give any further hints, where to find more design principles of Rock(-large) ? I do not mean the ultimate doc, the source code :-) Having quite some design- and development experience in high-performance file systems, also DB-like transactional ones, during the times when this had to be done in Assembler because of execution time and memory constraints, I expect quite some similarities. Reading the docs before reduces the amount of stupid questions. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-2-6-hot-object-cache-tp4658133p4658182.html Sent from the Squid - Users mailing list archive at Nabble.com.
