[
https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122754#comment-14122754
]
Benedict commented on CASSANDRA-6809:
-------------------------------------
I'm +1 on your over all intended approach, but I'd appreciate some elaboration
on what steps you've taken for testing:
* What platforms?
* What CPU config?
* What measurement of CPU time allocation? (10-20% bump may be reasonable if
its kernel time, but I'm a little surprised it has such an impact, as we'd be
talking about bulk writing large quantities of linear data, which should have
reasonably low CPU impact)
If you could post your in progress branches and tests to github so I can follow
what you're doing, that would be great
> Compressed Commit Log
> ---------------------
>
> Key: CASSANDRA-6809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6809
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Assignee: Branimir Lambov
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
>
> It seems an unnecessary oversight that we don't compress the commit log.
> Doing so should improve throughput, but some care will need to be taken to
> ensure we use as much of a segment as possible. I propose decoupling the
> writing of the records from the segments. Basically write into a (queue of)
> DirectByteBuffer, and have the sync thread compress, say, ~64K chunks every X
> MB written to the CL (where X is ordinarily CLS size), and then pack as many
> of the compressed chunks into a CLS as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
