httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: mod_socache_shmcb bogosity?
Date Fri, 11 Jun 2010 10:58:02 GMT
On Thu, Jun 10, 2010 at 07:28:55PM -0500, William Rowe wrote:
> 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]

Looking at this... currently the code assumes that expiry times of the 
objects are in time order, which is rather a leap of faith now.  It does 
allow expiry to be extremely cheap though; you just have to move the 
index pointers to the first still-valid entry.

I'd start to get rather worried about the performance impact of doing 
anything more complicated, esp if by "compress" you mean starting to 
actually moving data records about.

> 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.

Yeah, I was thinking of memcache w.r.t. staleness.  "lossy cache" is a 
tautology!

> 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.

Yes, this is a great point, and adding a "ids not random" hint seems 
like a really excellent idea.

Could we just use apr_hashfunc_default() as the hash and XOR the bytes 
of the returned int down to a single byte rather than import something 
else?

Regards, Joe

Mime
View raw message