Yes, that is correct. The SerializingCacheProvider stores row cache contents off heap. I believe you need JNA enabled for this though. Someone please correct me if I am wrong here.
The ConcurrentLinkedHashCacheProvider stores row cache contents on the java heap itself. Each cache provider has different characteristics so it's important to read up on how each works and even try it with your workload to see which one gives you better performance, if any at all. Faraaz On Sun, Sep 01, 2013 at 12:06:20AM -0700, S C wrote: > It is my understanding that row cache is on the memory (Not on disk). It could > live on heap or native memory depending on the cache provider? Is that right? > > -SC > > > > Date: Fri, 23 Aug 2013 18:58:07 +0100 > > From: b...@dehora.net > > To: user@cassandra.apache.org > > Subject: Re: row cache > > > > I can't emphasise enough testing row caching against your workload for > > sustained periods and comparing results to just leveraging the > > filesystem cache and/or ssds. That said. The default off-heap cache can > > work for structures that don't mutate frequently, and whose rows are not > > very wide such that the in-and-out-of heap serialization overhead is > > minimised (I've seen the off-heap cache slow a system down because of > > serialization costs). The on-heap can do update in place, which is nice > > for more frequently changing structures, and for larger structures > > because it dodges the off-heap's serialization overhead. One problem > > I've experienced with the on-heap cache is the cache working set > > exceeding allocated space, resulting in GC pressure from sustained > > thrash/evictions. > > > > Neither cache seems suitable for wide row + slicing usecases, eg time > > series data or CQL tables whose compound keys create wide rows under the > > hood. > > > > Bill > > > > > > On 2013/08/23 17:30, Robert Coli wrote: > > > On Thu, Aug 22, 2013 at 7:53 PM, Faraaz Sareshwala > > > <fsareshw...@quantcast.com <mailto:fsareshw...@quantcast.com>> wrote: > > > > > > According to the datastax documentation [1], there are two types of > > > row cache providers: > > > > > > ... > > > > > > The off-heap row cache provider does indeed invalidate rows. We're > > > going to look into using the ConcurrentLinkedHashCacheProvider. Time > > > to read some source code! :) > > > > > > > > > Thanks for the follow up... I'm used to thinking of the > > > ConcurrentLinkedHashCacheProvider as "the row cache" and forgot that > > > SerializingCacheProvider might have different invalidation behavior. > > > Invalidating the whole row on write seems highly likely to reduce the > > > overall performance of such a row cache. :) > > > > > > The criteria for use of row cache mentioned up-thread remain relevant. > > > In most cases, you probably don't actually want to use the row cache. > > > Especially if you're using ConcurrentLinkedHashCacheProvider and > > > creating long lived, on heap objects. > > > > > > =Rob > >
