[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072250#comment-14072250
]
Vijay commented on CASSANDRA-7438:
----------------------------------
{quote}
for starters, the first 1s in each gives 10x the throughput, and each is then
followed by some weirdly lengthy random pauses. SerializingCacheProvider sees a
21s latency pause
{quote}
Not sure about which 21 second pause, are you talking about thread creation
takes time specially during startup?
Anyways yes when the concurrency is lower here is the
http://pastebin.com/7fdY7kU1
{quote}
The SerializingCacheProvider actually has higher total throughput as well
{quote}
Obviously the overhead will be more because now we are serializing the row key
also off heap and there is safe points when calling JNI, but Let me clarify the
goal for the patch is not to run OOM when the cache size is bigger than the
heap.
If interested i can run some benchmarks to show that.
{quote}
Is this all over CQL3 native
{quote}
Yep it is thrift, and here is CQL3 w/ prepared. http://pastebin.com/auQkH325
> 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
>
>
> 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.2#6252)
