cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5863) In process (uncompressed) page cache
Date Wed, 27 Apr 2016 13:21:14 GMT


Branimir Lambov commented on CASSANDRA-5863:

In the latest couple of updates I did some renaming:
- {{BufferlessRebufferer}} to {{ChunkReader}} with {{rebuffer}} to {{readChunk}}
- {{BaseRebufferer}} to {{ReaderFileProxy}}
- {{SharedRebufferer}} to {{RebuffererFactory}} with factory method
- {{ReaderCache}} to {{ChunkCache}}

and updated some of the documentation. Hopefully this reads better now?

Switched to Caffeine as planned in CASSANDRA-11452:
- [better cache efficiency|]
on CachingBench which includes compaction, scans and collation from multiple sstables
- [cstar_perf with everything served off cache|]
shows equivalent performance, i.e. it does not degrade on heavy load
- [cstar_perf on smaller cache|]
shows better hit rate even with uniformly random access patterns (48.8 vs 45.4% as reported
by nodetool info)
- unlike LIRS, memory overheads are very controlled and specified [here|]:
at most 112 bytes per chunk including key, i.e. 0.2% for 64k chunks to 3% for 4k chunks.

And finally rebased to get dtest in sync:

> 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