<< So every time a page is requested, an array of comment ids for the page is resolved from memcache or database I mean, entire set of ids is retrieved from memcache, and the page is calculated from it.
On Tue, Sep 16, 2008 at 4:33 PM, Boris Partensky <[EMAIL PROTECTED]>wrote: > You mean a 2 phase fetch? So every time a page is requested, an array of > comment ids for the page is resolved from memcache or database (phase 1) and > then there is an additional multiget() for an array of comment ids (and > possible another query with IN() is issued for the ones that are missing, > Phase 2) is made, and text for comments is returned. Sure, that works. > > > > On Tue, Sep 16, 2008 at 4:23 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote: > >> >> On Tue, 16 Sep 2008, Boris Partensky wrote: >> >> Pages will shift as new items get inserted on top, so they all need to be >>> invalidated. Am I wrong? >>> I wouldn't try and do anything tricky unless you absolutely have to. If >>> query needs to be re-run every 10 min, >>> I don't see why bother. I would store multiple pages in cache, but that's >>> just so you don't have to paginate in memory upon every request. >>> >> >> Even if your total result set is reasonably large, if you just store the >> "post IDs" or whatever you can cache the entire set as a single key. 1000 >> 32-bit IDs is still only 4KB. I doubt you can even show a speed difference >> between fetching a 4KB cache value and a 40 byte cache value. >> >> If you just have an array of post IDs, doing the pagination in the app >> server is also unlikely to take any serious amount of time - just a few >> microseconds to slice out of the 4KB array. >> >> I wouldn't advocate this for result sets with thousands and thousands of >> elements, but we use it successfully for sets like "Fans of an Artist" or >> "Friends of a user" which usually are very small and only occasionally go >> into the several hundreds or thousands range. >> >> -Todd >> > > > > -- > --Boris > -- --Boris
