dustin at spy.net
Sun Sep 30 07:33:15 UTC 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached