[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071692#comment-14071692
]
Benedict commented on CASSANDRA-7438:
-------------------------------------
The posted results have some really weird things going on... 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 (even more weirdly given < 21s have passed in total). Then just as
strangely, the offheap cache has a huge dip in performance part way through.
The SerializingCacheProvider actually has higher total throughput as well. I
think we need to look more closely at the benchmark behaviour. Is this all over
CQL3 native? prepared? could be the 1200 threads are incurring a very high cost
to preparing the statements (since they get re-prepared), which might require a
fix, but could be smoothed out for now by running for longer and with fewer
threads; but this doesn't explain the massive discrepancy in pause for the
first few seconds, nor the decline in performance seen by the offheap provider
in the middle
> 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)
