On 23/01/2013 5:04 a.m., babajaga wrote:
> 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) ?
The Measurement-Factory would be the best place to ask that. As far as I
am aware at this stage it was going to be the same as existing Rock with
just a list of multiple pages per object. But that was discussed months
ago and the particulars are likely to have changed due to code
requirements since.
> 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.
Very likely. It is a database of URI entities after all.
Amos
Received on Wed Jan 23 2013 - 05:06:10 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 23 2013 - 12:00:05 MST