[
https://issues.apache.org/jira/browse/CASSANDRA-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175726#comment-13175726
]
Pavel Yaskevich commented on CASSANDRA-3623:
--------------------------------------------
Pavel, it doesnt show the opposite it actually shows the time spent is 98% in
the snappy library and only 2% in the remaining part of the code. Where as in
the earlier case we spend 58% of the time in Snappy and rest in the other part
of the code. Snappy/decompression is definitely the bottleneck... all i am
saying is that now we are more efficient and thats the only bottleneck.
Nacked percentages do not say anything that is why tool also shows the time
spent in the method, and it says that with your patch snappy performance
noticeably degraded. What I'm trying to say is, you might be trying to optimize
the wrong thing which could lead to the degraded performance of the
decompression, unpredictable consequences for SSTable release and possibly
other implications that we don't see right now.
Also I wanted to ask you: what do "NetRxKb" and "NetTxKb" show in this case
(sorry I didn't use the tool you are using)? Looks like "RdLat" correlates with
those properties.
bq. Plz note i am not selling this patch ;) I am trying to find a better
performance for our use case which needs compression... I am completely open
for other options.
I understand that but we can't really commit the code that optimizes one
specific use-case that could lead to bad implications to other people.
> use MMapedBuffer in CompressedSegmentedFile.getSegment
> ------------------------------------------------------
>
> Key: CASSANDRA-3623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3623
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1
> Reporter: Vijay
> Assignee: Vijay
> Labels: compression
> Fix For: 1.1
>
> Attachments: 0001-MMaped-Compression-segmented-file-v2.patch,
> 0001-MMaped-Compression-segmented-file.patch,
> 0002-tests-for-MMaped-Compression-segmented-file-v2.patch
>
>
> CompressedSegmentedFile.getSegment seem to open a new file and doesnt seem to
> use the MMap and hence a higher CPU on the nodes and higher latencies on
> reads.
> This ticket is to implement the TODO mentioned in CompressedRandomAccessReader
> // TODO refactor this to separate concept of "buffer to avoid lots of read()
> syscalls" and "compression buffer"
> but i think a separate class for the Buffer will be better.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
