Hi Matija,
Leveraging page cache yields good results and if accounted for can provide you with performance increase on read side I would like to leverage the page cache to improve read performance. How this can be done? Best Regards, Julian. ---- On Mon, 13 Mar 2017 03:42:32 +0530 preetika tyagi <preetikaty...@gmail.com> wrote ---- I see. Thanks, Arvydas! In terms of eviction policy in the row cache, does a write operation invalidates only the row(s) which are going be modified or the whole partition? In older version of Cassandra, I believe the whole partition gets invalidated even if only one row is modified. Is that still true for the latest release (3.10). I browsed through many online articles and tutorials but cannot find information on this. On Sun, Mar 12, 2017 at 2:25 PM, Arvydas Jonusonis <arvydas.jonuso...@gmail.com> wrote: You can experiment quite easily without even needing to restart the Cassandra service. The caches (row and key) can be enabled on a table-by-table basis via a schema directive. But the cache capacity (which is the one that you referred to in your original post, set to 0 in cassandra.yaml) is a global setting and can be manipulated via JMX or nodetool (nodetool setcachecapacity). Arvydas On Sun, Mar 12, 2017 at 9:46 AM, preetika tyagi <preetikaty...@gmail.com> wrote: Thanks, Matija! That was insightful. I don't really have a use case in particular, however, what I'm trying to do is to figure out how the Cassandra performance can be leveraged by using different caching mechanisms, such as row cache, key cache, partition summary etc. Of course, it will also heavily depend on the type of workload but I'm trying to gain more understanding of what's available in the Cassandra framework. Also, I read somewhere that either row cache or key cache can be turned on for a specific table, not both. Based on your comment, I guess the combination of page cache and key cache is used widely for tuning the performance. Thanks, Preetika On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <matija0...@gmail.com> wrote: Hi, In 99% of use cases Cassandra's row cache is not something you should look into. Leveraging page cache yields good results and if accounted for can provide you with performance increase on read side. I'm not a fan of a default row cache implementation and its invalidation mechanism on updates so you really need to be careful when and how you use it. There isn't much to configuration as there is to your use case. Maybe explain what are you trying to solve with row cache and people can get into discussion with more context. Regards, Matija On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <preetikaty...@gmail.com> wrote: Hi, I'm new to Cassandra and trying to get a better understanding on how the row cache can be tuned to optimize the performance. I came across think this article: https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html And it suggests not to even touch row cache unless read workload is > 95% and mostly rely on machine's default cache mechanism which comes with OS. The default row cache size is 0 in cassandra.yaml file so the row cache won't be utilized at all. Therefore, I'm wondering how exactly I can decide to chose to tweak row cache if needed. Are there any good pointers one can provide on this? Thanks, Preetika
