[
https://issues.apache.org/jira/browse/CASSANDRA-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258961#comment-15258961
]
Pavel Yaskevich commented on CASSANDRA-5863:
--------------------------------------------
[~blambov] What I meant is similar to per-file map with shared eviction
strategy, if you already have that in mind - perfect :) What you are saying
regarding rebufferers makes sense to me, I was just trying to advocate for is
providing better distinction between BufferlessRebufferer and Rebufferer at
least via naming so "rebuffer" or "buffer processor" is the thing with holds
the actual processing logic and BufferlessRebufferer is essentially "data
source" or "data provider/producer" for it. I'm asking to do this because for
me, as an observer of the changes, the distinction wasn't clear from the first
glimpse, what made it especially confusing is rebuffer method itself.
> In process (uncompressed) page cache
> ------------------------------------
>
> Key: CASSANDRA-5863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5863
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: T Jake Luciani
> Assignee: Branimir Lambov
> Labels: performance
> Fix For: 3.x
>
>
> Currently, for every read, the CRAR reads each compressed chunk into a
> byte[], sends it to ICompressor, gets back another byte[] and verifies a
> checksum.
> This process is where the majority of time is spent in a read request.
> Before compression, we would have zero-copy of data and could respond
> directly from the page-cache.
> It would be useful to have some kind of Chunk cache that could speed up this
> process for hot data, possibly off heap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
