[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228523#comment-14228523
]
Vijay commented on CASSANDRA-7438:
----------------------------------
{quote}I would break out the performance comparison with and without warming up
the cache so we know how it performs when you aren't measuring the resize
pauses.{quote}
Yep and in stedy state it is similar to get and I have verified that the
latency is due to rehash. Better benchmarks on bug machines will be done on
Monday.
Unfortunately -1 on partitions, it will be a lot more complex and will be hard
to understand for users. If we have to expand the partitions, we have to figure
out a better consistent hashing algo. "Cassandra within Cassandra may be". More
over we will end up having the current code as is to move maps and queues
offheap. Sorry I don't understand the argument of code complexity.
If we are talking about code complexity. The unsafe code is 1000 lines
including the license headers :)
The current contention topic is weather to use cas for locks. Which is showing
higher cpu cost and I agree with Pavel on latencies as shown in the numbers.
> Serializing Row cache alternative (Fully off heap)
> --------------------------------------------------
>
> Key: CASSANDRA-7438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: Linux
> Reporter: Vijay
> Assignee: Vijay
> Labels: performance
> Fix For: 3.0
>
> Attachments: 0001-CASSANDRA-7438.patch, tests.zip
>
>
> Currently SerializingCache is partially off heap, keys are still stored in
> JVM heap as BB,
> * There is a higher GC costs for a reasonably big cache.
> * Some users have used the row cache efficiently in production for better
> results, but this requires careful tunning.
> * Overhead in Memory for the cache entries are relatively high.
> So the proposal for this ticket is to move the LRU cache logic completely off
> heap and use JNI to interact with cache. We might want to ensure that the new
> implementation match the existing API's (ICache), and the implementation
> needs to have safe memory access, low overhead in memory and less memcpy's
> (As much as possible).
> We might also want to make this cache configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
