[jira] [Comment Edited] (CASSANDRA-9738) Migrate key-cache to be fully off-heap

["Ariel Weisberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14716905#comment-14716905 ] 

Ariel Weisberg edited comment on CASSANDRA-9738 at 8/28/15 3:00 PM:
--------------------------------------------------------------------

How big is the realistic size range of key cache values?

The only thing that makes me uncomfortable right now is the buffer handling for the serializing the key cache value in serializedSize(). Resizing in the loop is 4k at a time and not doubling. I think it at least needs to double to manage whatever the worst case is.

It seems to me like the right tack on failure is to allocate the correct size buffer by calculating the size the old way or double (for lg(n)). Doubling is fine if we really never expect sane data models to hit it. Doubling is not going to be great for people to hit under real world conditions especially if they have to do it several times.

It's tempting to ask to have 10189 expanded to be "make this stuff fast" and then do it the old way in this change set, but I could be convinced if there isn't a really bad corner case.

Also next time could you wait for +1 to squash? I can't see your last few change sets once you squash. I am guilty of this too and now I know how it feels.


was (Author: aweisberg):
How big is the realistic size range of key cache values?

The only thing that makes me uncomfortable right now is the buffer handling for the serializing the key cache value in serializedSize(). Resizing in the loop is 4k at a time and not doubling. I think it at least needs to double to manage whatever the worst case is.

It seems to me like the right tack on failure is to allocate the correct size buffer by calculating the size the old way or double (for lg(n)). Doubling is fine if we really never expect sane data models to hit it. Doubling is not going to be great for people to hit under real world conditions especially if they have to do it several times.

It's tempting to ask to have 10189 expanded to be "make this stuff fast" and then do it the old way in this change set, but I could be convinced if there isn't a really bad corner case.

Also next time could you wait +1 to squash? I can't see your last few change sets once you squash. I am guilty of this too and now I know how it feels.

> Migrate key-cache to be fully off-heap
> --------------------------------------
>
>                 Key: CASSANDRA-9738
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>             Fix For: 3.0 beta 2
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some benefit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)