<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Sep 19, 2007, at 7:02 , K J wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>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.<span class="Apple-converted-space"> </span><br> </div><div>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.</div><div> </div><div>What do you guys think of this solution?</div></span></blockquote><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Have you looked at the proposed solutions (i.e. tags and regex)?<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>On Sep 19, 2007, at 7:07 , K J wrote:</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><div>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.</div><div> </div><div>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?</div></blockquote><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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?<br class="webkit-block-placeholder"></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>-- </div><div>Dustin Sallings</div><br class="Apple-interchange-newline"></span> </div><br></body></html>