On 03/15/2014 12:50 AM, babajaga wrote:
>> This is how Rock store does it, essentially: Rock store index does not
> store the real location of the object on disk but computes it based on
> the hash value.<
> Which means, the mapping URL-hash -> slot_# is _not_ fixed (predictable).
I am simplifying a bit, but the mapping of the URL to the first slot on
disk is essentially determined by the URL hash. The other slots are not
important for this discussion because you have to load the first slot to
know where the next slot (or slots) are -- the theoretically possible
scheme where the next slot location is also determined by a hash is not
practical for storing large objects.
>>> Positive consequence: No rebuild of the in-memory-table necessary, as
>>> there is none. Avoids the time-comsuning rebuild of rock-storage-table from
>>> disk.
>> If you do not build the index,
>> you have to do a disk I/O to fetch the first slot of the candidate
>> object on _every_ request.
> Not necessarily to do a disk I/O, but to do an I/O. Still, underlying
> OS-buffering/blocking is happening.
In most environments where Rock makes sense, Squid will be doing disk
I/O because the large database means virtually zero filesystem buffer
cache hit ratio.
> Besides, for a HIT you have to do the I/O anyway.
> So, the amount of "unnecessary disk-I/Os" would be the (squid-MISSes - not
> in OS/buffers residing disk-blocks).
Yes, of course. Also, depending on how you implement this, you may have
to do extra disk I/Os to delete objects from the cache (to make room for
new ones).
> Which leads to a good compromise: Direct hashing would allow the slow
> population of the optional translation-table.
That compromise would not be "good" for most targeted environments. Most
folks who care about performance would gladly pay for the extra RAM it
takes to store the index than to see Squid slowing every request down
even more (which usually means buying more servers).
Can a disk-only cache function correctly? Sure! Is it a good idea for a
performance-sensitive deployment that Rock targets? No.
Alex.
Received on Sun Mar 16 2014 - 18:14:52 MDT
This archive was generated by hypermail 2.2.0 : Mon Mar 17 2014 - 12:00:05 MDT