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 <agrawal.tus...@gmail.com> wrote: > > 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, Dan Kinder <dkin...@turnitin.com > <mailto:dkin...@turnitin.com>> wrote: > >> 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 <gra...@vast.com >> <mailto:gra...@vast.com>> wrote: >> On read or write? >> >> https://issues.apache.org/jira/browse/CASSANDRA-7039 >> <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 <dkin...@turnitin.com >>> <mailto:dkin...@turnitin.com>> wrote: >>> >>> 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 >>> compression increases my CPU load by ~2x") >>> >>> -dan >> >> >> >> >> -- >> Dan Kinder >> Senior Software Engineer >> Turnitin – www.turnitin.com <http://www.turnitin.com/> >> dkin...@turnitin.com <mailto:dkin...@turnitin.com>
