Changing expiration

[Dustin Sallings]

On Sep 29, 2007, at 19:35, K J wrote:

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

	If the comment scores are changing independently, you can store them  
independently.  You could, for example, make them counters.  The same  
request that's asking for the article keys can include a request for  
the counter keys as well.

	Doing so means that your representations of your data are always  
accurate, but at a reasonably low cost.

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

	I suppose that it's possible depending on the design.  The semantics  
sound similar to flush with respect to the delay mechanism.  It does  
make more sense to me than flush in that case, although that's not  
saying a lot.  :)

	It does have a bit of a ``just don't do that'' feel, though.  Most  
search engines seem fast enough that you wouldn't necessarily bother  
caching their results.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070930/22fd09d9/attachment.htm