Re: [squid-users] Re: Automatic StoreID ?

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.
Received on Fri Mar 14 2014 - 14:09:48 MDT