cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5863) In process (uncompressed) page cache
Date Tue, 26 Apr 2016 21:28:13 GMT


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:
>             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
> 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

View raw message