Re: compression cpu overhead

To clarify, writes have no *immediate* cpu cost from adding the write to the memtable, however the compression overhead cost is paid when writing out a new SSTable (whether from flushing a memtable or compacting), correct? So it sounds like when reads >> writes then Tushar's comments are accurate,

Re: compression cpu overhead

You won't see any overhead on writes because you don't actually write to sstables when performing a write. Just the commit log & memtable. Memtables are flushes asynchronously. > On Nov 4, 2015, at 1:57 AM, Tushar Agrawal wrote: > > For writes it's negligible. For reads it makes a significan

Re: compression cpu overhead

For writes it's negligible. For reads it makes a significant difference for high tps and low latency workload. You would see up to 3x higher cpu with LZ4 vs no compression. It would be different for different h/w configurations. Thanks, Tushar (Sent from iPhone) > On Nov 3, 2015, at 5:51 PM, D

Re: compression cpu overhead

Most concerned about write since that's where most of the cost is, but perf numbers for a any workload mix would be helpful. On Tue, Nov 3, 2015 at 3:48 PM, Graham Sanderson wrote: > On read or write? > > https://issues.apache.org/jira/browse/CASSANDRA-7039 and friends in 2.2 > should make some

Re: compression cpu overhead

On read or write? https://issues.apache.org/jira/browse/CASSANDRA-7039 and friends in 2.2 should make some difference, I didn’t immediately find perf numbers though. > On Nov 3, 2015, at 5:42 PM, Dan Kinder wrote: > > Hey all, > > Just w

compression cpu overhead

Hey all, Just wondering if anyone has done seen or done any benchmarking for the actual CPU overhead added by various compression algorithms in Cassandra (at least LZ4) vs no compression. Clearly this is going to be workload dependent but even a rough gauge would be helpful (ex. "Turning on LZ4 co