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.Received on Tue Jan 22 2013 - 16:04:50 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 23 2013 - 12:00:05 MST