[
https://issues.apache.org/jira/browse/CASSANDRA-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257648#comment-15257648
]
Branimir Lambov commented on CASSANDRA-5863:
--------------------------------------------
bq. we might want to be more conservative and indicate early that requested
length is bigger than number of available bytes
This is not that trivial for rebuffering -- the requested length would normally
be bigger than the number of available bytes during the last {{reBuffer()}}
call on the file, thus the changes required to implement this check are too
substantial to be within the scope of this ticket.
bq. I saw a possibility to unify bufferless with other implementations because
essentially the question is - where original data comes from - directly from
the channel or already mmap'ed buffer
I started with a single implementation and quickly found out it is not
sufficient. There are other things to take into account:
- Does the buffer hold all the data you need for decompression?
- Is it properly aligned so it can be cached?
- How do you signal that you are done with it so it can be reclaimed?
- Do you need to copy anything from one buffer to another to make this work?
If you still think a single interface / removing {{Rebufferer}} could work
efficiently, would you elaborate and, possibly, provide some code?
bq. I think we will have to tackle it first since it would directly affect
rebufferer/cache logic
The logic is clearly defined for this round. This patch is targeted at 3.x
where we can't change sstable format in any way, and support for this format
will be required long in the future.
> 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)
