Changing expiration

[K J]

>
>  That just doesn't sound expensive to me.  If you have each comment in its
> own cache entry, and a cache entry for the list, you can replace the
> components or the list independently, and then do one cache query to get the
> list, to convert the id list to a comment list.  If the list, or any
> comments are missing, you'll, of course, need to fetch those.
>
>
> After that, your filter op can happen on the client:
>
>
> comments = [c for c in all_comments if c.rating > 2]
>
>
> You can cache *that* as well if you do find it to be expensive to
> recreate.  Then you just need to clear potentially cached filtrations when
> updating comments or comment lists.
>
>
> Using the above, I'd expect you to be able to have excellent cache
> accuracy and really good performance.
>

Currently I only store the vote score in the comment itself.  You are saying
I should store it in the comments listing too?

I might give that a try, and do the comment filtering in the php app
instead.

There are some other examples though, where it gets really expensive to
re-calculate on every change.  For instance search results.  If just one
item's attributes change (which happens probably once every 10 seconds), a
whole range of search queries would be invalided.

Take for example, Myspace's browse page.  There are multiple options you can
select, such as age, zip code, sex, etc.  Just having one user change his
zip code would invalidate all the combinations that involve the zip code.
If the site is busy, invalidations could be occurring every few seconds,
putting lots of load on the server.  Then, at night when there's little
traffic, hardly any updates are happening.

Would this type of situation warrant what I was suggesting?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070930/70e9ec59/attachment.htm