[
https://issues.apache.org/jira/browse/CASSANDRA-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253923#comment-14253923
]
Benedict commented on CASSANDRA-8520:
-------------------------------------
I mean touches sstables and not memtables, because the majority of reads work
is this way. Ideally we would do this test against a new better storage format
as well, and certainly we would optimise the read path.
bq. It's just not worth it from risk perspective. Can't throw away proven and
working code for some uncertain benefit.
Honestly I think one of the most compelling reasons to move is precisely to
throw away a lot of error prone concurrent code, over time. We spend a great
deal of time chasing such problems, and realising the code isn't as proven and
working as we would like. This isn't committing to a huge rewrite, but to a
world where such a rewrite is possible.
Either way, I'm not going to campaign for this or any specific approach, I just
wanted to ask the question upfront so that it could be thought about.
> Prototype thread per core
> -------------------------
>
> Key: CASSANDRA-8520
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8520
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jonathan Ellis
> Labels: performance
> Fix For: 3.1
>
>
> Let's prototype the best possible scenario for how well we can perform with a
> thread per core design by simplifying everything we can. For instance,
> - No HH, no RR, no replication at all
> - No MessagingService
> - No compaction (so test a workload w/o overwrites)
> - No repair
> - Just local writes and reads
> If we can't get a big win (say at least 2x) with these simplifications then I
> think we can say that it's not worth it.
> If we can get a big win, then we can either refine the prototype to make it
> more realistic or start working on it in earnest.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
