[
https://issues.apache.org/jira/browse/CASSANDRA-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255189#comment-15255189
]
Pavel Yaskevich commented on CASSANDRA-5863:
--------------------------------------------
[~blambov] Sorry for the delay, I'm planing to look at the code shortly. While
I'm on it, do you think it would be possible (if it hasn't been done already)
to simulate situation when single key read touches multiple SSTables (aka
multi-collation case)? That, I think, might be one of the interesting cases for
cache performance even without writes present, since it closely reflects some
of the most common real world situations, which require multiple index/data
reads per request generating different eviction patterns.
> 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)
