3 ms·

I don’t think anyone avoiding talking about single threaded bottlenecks. The main one that matters is on sstable streaming during bootstrap, and the zero copy s

by jjirsa 5y ago

I don’t think anyone avoiding talking about single threaded bottlenecks. The main one that matters is on sstable streaming during bootstrap, and the zero copy streaming was directly to address that. There’s not really any single threaded pieces in cassandra that matter beyond that? If anything the opposite is true - thread pools everywhere leading to context switching and data copying for no reason. On a deeper note, it probably says something about the user base that people who don’t run it in prod think the perf is really bad and yet there are very few people submitting perf improvement patches. Maybe most of the power users aren’t that worried about perf because they either know how to tune a JVM or they happen to size their clusters based on bytes on disk?

throwdbaaway 5y ago
Other than streaming, a less obvious single threaded bottleneck would be the LCS compaction, with a rather ugly workaround of using multiple keyspaces as noted in https://issues.apache.org/jira/browse/CASSANDRA-7949#comment-14223036 https://issues.apache.org/jira/browse/CASSANDRA-7949#comment... With scylla TPC approach, there will be one shard per core, and I think that shall allow more LCS compactions to run in parallel. Theoretically. I have seen the workaround on a very large cassandra cluster. Meanwhile, I never thought to myself that "well, the 200ms p99 with g1gc sure is nice, but my users would be so happy if I can lower it to 20ms". So, if I am scylla, TPC would be my main selling point, coupled with real world examples, but somehow they want to focus on p99.