But then you'd still be caching the same things memcached is, so unless you have a lot more ram you'll presumably miss the same rows too.
The only 2-layer approach that makes sense to me would be to have cassandra keys cache at 100% behind memcached for the actual rows, which will actually reduce the penalty for a memcache miss by half-ish. On Wed, Mar 31, 2010 at 1:32 PM, David Strauss <da...@fourkitchens.com> wrote: > Or, if faking memcached misses is too high a price to pay, queue some > proportion of the reads to replay asynchronously against Cassandra. > > On Wed, 2010-03-31 at 11:04 -0500, Jonathan Ellis wrote: >> Can you redirect some of the reads from memcache to cassandra? Sounds >> like the cache isn't getting warmed up. >> >> On Wed, Mar 31, 2010 at 11:01 AM, James Golick <jamesgol...@gmail.com> wrote: >> > I'm testing on the live cluster, but most of the production reads are being >> > served by the cache. It's definitely the right CF. >> > >> > On Wed, Mar 31, 2010 at 8:30 AM, Jonathan Ellis <jbel...@gmail.com> wrote: >> >> >> >> On Wed, Mar 31, 2010 at 12:01 AM, James Golick <jamesgol...@gmail.com> >> >> wrote: >> >> > Okay, so now my row cache hit rate jumps between 1.0, 99.5, 95.6, and >> >> > NaN. >> >> > Seems like that stat is a little broken. >> >> >> >> Sounds like you aren't getting enough requests for the >> >> getRecentHitRate to make sense. use getHits / getRequests. >> >> >> >> But if you aren't getting enough requests for getRecentHitRate, are >> >> you sure you're tuning the cache on the right CF for your 35ms test? >> >> Are you testing live? If not, what's your methodology here? >> >> >> >> -Jonathan >> > >> > > > > >
