cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5863) In process (uncompressed) page cache
Date Sat, 23 Apr 2016 07:48:13 GMT

    [ 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)

Mime
View raw message