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.
