On Sep 19, 2007, at 7:02 , K J wrote:
I'm facing the same problem here. From the responses I'm guessing
that most of you think it's better to cache each individual
"article" and perhaps the article titles for display. Listings
still hit the database directly. The only savings would be that
the app wouldn't have to do another SQL to fetch the article titles/
links/data, as it can get it from the cache.
However, is there no way to cache these pages effectively? For
instance, what if say I set a default expiration time for anything
that's not on page 1. Then whenever an article gets inserted, the
first 10 pages are purged, while pages 11 onwards are expired on
their own.
What do you guys think of this solution?
Have you looked at the proposed solutions (i.e. tags and regex)?
In general, having multiple copies of the same data seems like a bad
idea. When you cache the article, you're avoiding the DB hit. When
you cache the page, you're memoizing a template render. These are
solving different problems.
On Sep 19, 2007, at 7:07 , K J wrote:
For instance, I'd like to cache my search pages, as they are really
database/cpu intensive. For instance, on a social networking site
someone could be searching based on sex, height, religion, hobbies,
location, and other combined criteria. This sort of query hits the
databse hard, and it wouldn't take too many of those to crash the
db server.
In this case wouldn't it be great to cache every single search that
comes in, so that in a duplicate search the app wouldn't have to
hit the database again?
What do you expect the hit ratio to be on this? What aspect of your
search is intensive? Are you, perhaps pulling too much data out with
your search results such that you're pulling out information on each
user that you could look up from cache?
--
Dustin Sallings
