On 03/14/2014 06:34 AM, babajaga wrote: > Instead of first mapping the URL to a memory-resident table, keeping > pointers (file-id, bucket no.) to the real location of the object on disk, a > hash-value, derived from the URL could directly be used to designate the > storage location on disk, avoiding the translation table, squid uses. 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. > 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. While Rock store can avoid building the memory-resident index, you actually want that table in most cases: 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. Without that disk I/O, Squid would not know whether it has a hit or a miss because _every_ URL corresponds to a valid location on disk. You have an infinite number of URLs pointing to the same location and, without a memory-resident table, you do not know what is actually stored there (if anything at all) until you do that disk I/O. For reverse proxy caches with very high hit ratios, avoiding the rebuild may indeed be a good optimization where warmup time is more important than speed. Most such proxies have small caches that do not require a long rebuild, making the need for that optimization moot though. The building of the index needs to be optimized, but that is a different story. Note that Rock store can cache new objects while building the index (because the index does not store the object location). Cheers, Alex.
