[jira] [Comment Edited] (CASSANDRA-5863) In process (uncompressed) page cache

["Branimir Lambov (JIRA)" <ji...@apache.org>]

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

Branimir Lambov edited comment on CASSANDRA-5863 at 3/11/16 5:48 PM:
---------------------------------------------------------------------

Work-in-progress patch here:
|[code|https://github.com/blambov/cassandra/tree/5863-page-cache]|[utest|http://cassci.datastax.com/job/blambov-5863-page-cache-testall/]|[dtest|http://cassci.datastax.com/job/blambov-5863-page-cache-dtest/]|[cstar_perf|http://cstar.datastax.com/tests/id/aff1cbdc-e6bf-11e5-9473-0256e416528f]|

The patch mainly refactors things around {{\[Compressed\]RandomAccessReader}} to allow caching to be inserted between the RAR and decompressor, and adds a basic cache built around guava's {{LoadingCache}} and {{BufferPool}}, avoiding any additional copying. It could also be used to cache non-memmapped reads from uncompressed tables, though that is not implemented yet.

Perf results show this to be viable even in this basic form, as there's a clear performance benefit. It is more pronounced looking at the local read latency (taken from {{nodetool tablestats}}):
| |node 1|node2|node3||
|baseline|0.197 ms|0.194 ms|0.196 ms|
|with uncompressed chunk cache|0.172 ms|0.170 ms|0.158 ms|
|chunk cache and buffer pool off|0.217 ms|0.210 ms|0.206 ms|
as well as in single-node in-memory runs on my local machine where cache on takes reads from 19k to 23k per second, with local read latency going from 64 to 21 microseconds (for comparison, the figures for memtable reads were 24k and 13).

The next steps are:
- Take care of the possibility that a buffer may be evicted (and deallocated) while in use.
- Add hit/miss/latency metrics.
- Prepare some (fixed-seed) workloads that include random reads, scans, compaction and anything else that may be of interest.
- Start experimenting: existing or custom implementation, eviction strategies (LIRS seems simple enough and very suitable), etc.


was (Author: blambov):
Work-in-progress patch here:
|[code|https://github.com/blambov/cassandra/tree/5863-page-cache]|[utest|http://cassci.datastax.com/job/blambov-5863-page-cache-testall/]|[dtest|http://cassci.datastax.com/job/blambov-5863-page-cache-dtest/]|[cstar_perf|http://cstar.datastax.com/tests/id/aff1cbdc-e6bf-11e5-9473-0256e416528f]|

The patch mainly refactors things around {{\[Compressed\]RandomAccessReader}} to allow caching to be inserted between the RAR and decompressor, and adds a basic cache built around guava's {{LoadingCache}}. Perf results show this to be viable even in this basic form, as there's a clear performance benefit. It is more pronounced looking at the local read latency (taken from {{nodetool tablestats}}):
Work-in-progress patch here:
|[code|https://github.com/blambov/cassandra/tree/5863-page-cache]|[utest|http://cassci.datastax.com/job/blambov-5863-page-cache-testall/]|[dtest|http://cassci.datastax.com/job/blambov-5863-page-cache-dtest/]|[cstar_perf|http://cstar.datastax.com/tests/id/aff1cbdc-e6bf-11e5-9473-0256e416528f]|

The patch mainly refactors things around {{\[Compressed\]RandomAccessReader}} to allow caching to be inserted between the RAR and decompressor, and adds a basic cache built around guava's {{LoadingCache}}. Perf results show this to be viable even in this basic form, as there's a clear performance benefit. It is more pronounced looking at the local read latency (taken from {{nodetool tablestats}}):
| |node 1|node2|node3||
|baseline|0.197 ms|0.194 ms|0.196 ms|
|with uncompressed chunk cache|0.172 ms|0.170 ms|0.158 ms|
|chunk cache and buffer pool off|0.217 ms|0.210 ms|0.206 ms|
as well as in single-node runs on my local machine where cache on takes reads 

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