[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192922#comment-14192922
]
Pavel Yaskevich commented on CASSANDRA-7438:
--------------------------------------------
I looked trough the patch and everything looks good, but one small thing:
- FBUtilities.newRowCacheProvider needs it's argument renaming, because it
looks like it has been copied from FBUtilities.newPartitioner and has old
names, so instead of paritioner it should be rowCacheClassName and "rowCache"
as the last argument for FBUtilities.construct(...).
I just want to address Robert's comment regarding
EncodedData{Input/Output}Stream: I agree that longs returned by version 1 UUID
are not that compressible and vint is actually going to add 1 byte on top of
long (which is pretty easy to test), but the good thing is that although we
loose 2 bytes in long serialization we actually win back at least 2 bytes by
vint encoding length of the key and, in best case, if key size is less than 127
(which is highly likely) we are actually going to win 3 bytes which makes in
total 1 byte profit from encoding :)
> 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.3.4#6332)
