You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2015/01/07 23:40:36 UTC

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

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

Jonathan Ellis edited comment on CASSANDRA-8520 at 1/7/15 10:40 PM:
--------------------------------------------------------------------

What I really want to get is less "what can we expect from round 1" and more, "if we ignore all the complexities, what is something close to an upper bound on the performance we can expect?"

(Which probably won't actually be useful as a starting point for round 1, and I'm fine with that.)


was (Author: jbellis):
What I really want to get is, "if we ignore all the complexities, what is something close to an upper bound on the performance we can expect?"

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