[jira] [Commented] (CASSANDRA-8520) Prototype thread per core

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253863#comment-14253863 ] 

Benedict commented on CASSANDRA-8520:
-------------------------------------

bq. If we can't get a big win (say at least 2x)

We should be careful when setting up the goalposts in advance. If we see a dramatic shift in location of bottleneck without a dramatic shift in total performance, that simply means it's not _yet_ worth it. A change like this will have to go hand-in-hand with other changes to make the most of it: new memtables, new commit log, faster storage format, in process page cache, AIO for disk operations, ... we can strip even a lot of this out to see what the dividends will be, of course, but in many ways this is much more of an opening of the doors to many improvements in performance and reliability.

What's the maximal scope for proving/disproving this as a way forwards? If we rule it out without taking it actually quite far, we may simply be premature. Alternatively if we can see modest improvements with only a small exploration of the potential it might be enough to suggest commital is a good thing. Unfortunately we just cannot explore many of these improvements without thread-per-core.

An initial goal might be benchmarking in-memory read workloads that don't touch memtables, so we can isolate as much of the system as possible. We will still want to explore some of the natural optimisations we can make, and probably shutdown many of the other things the system is doing to ensure we get a good picture of yield.

> 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)