hi todd ! thanks for your reply! That means I should store all comment ids as array in one key ?
example: forum_id:100 => 1,2,3,4,5,6,7,8,9 etc. after retrieving these ids from the main key should I query them via mysql or should I have all single comments as memcache value ? example: forum_id:100 => 1,2,3,4,5,6,7,8,9 get forum_id:100 get forum_id:100_commentid:1 get forum_id:100_commentid:2 get forum_id:100_commentid:3 get forum_id:100_commentid:4 get forum_id:100_commentid:5 get forum_id:100_commentid:6 get forum_id:100_commentid:7 get forum_id:100_commentid:8 get forum_id:100_commentid:9 what do you think ? could you give an example of your configuration ? kind regards dan On 16 Sep., 22:23, 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
