httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: mod_socache_shmcb bogosity?
Date Fri, 11 Jun 2010 00:28:55 GMT
On 6/10/2010 7:15 AM, Joe Orton wrote:
> On Wed, Jun 09, 2010 at 11:30:45AM -0500, William Rowe wrote:
>> Just noticed that our shmcb socache never replaces an identical node
>> on ->store, leading to multiple entries for the same id (with different
>> expiries and data, obviously).
>> Is this deliberate?  What is the distcache/memcached/dbm behavior, are
>> they all replacing the existing node?  What is the programming contract?
> It's a cyclic buffer - the most recently stored entry should be returned 
> by a retrieve operation... the old entry should effectively be invisible 
> to the caller.  Is that not working?

Have not checked specifically, the problem I observed was ejecting other
unexpired elts as other records were repeatedly updated.

It seems the simple fix is to change the pre-store free logic,

 * expire records [do this only if space needed?  right now, it's on all stores]

 * if enospace, compress removed/expired records until space is available

 * if still enospace, drop the first-to-expire [current behavior]

Seem sensible?

> w.r.t. contract: specific behaviour will vary across the providers; 
> could nail down the ->retrieve API with a bunch of stuff which is *not* 
> guaranteed, I suppose, is that what you're thinking of?  "object 
> returned may be out-of-date/stale, etc"

If we know it may be stale, we should declare that (in the shmcb case, this
never happens, IIRC).  We obviously should declare this is a lossy cache.

In other events, the current logic of max 256 caches keyed on the first byte
of ID is not sufficiently resuable.  What do folks suggest for the most efficient
hash method?

I'm thinking we add to the hints that hashing is required, or assuring that
the data is 8-bit hashed already and leading bytes are just fine for choosing
subcaches.  In order to achieve the goal above of compressing records, it would
seem sensible to favor more subcaches with no more than 64k worth of elts, which
ensures any compressing memcpy's are more efficient.

View raw message