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/05 19:01:35 UTC

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

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

Jonathan Ellis commented on CASSANDRA-8520:
-------------------------------------------

Agreed that this is the "correct" model other things being equal, but other things are not equal.  In particular we have other features to build that are just as important as performance.  So if we're going to sign up for the pain of a major refactor, I want to know

# How much pain is it really?  I.e. how long are we going to be hitting pause on merging other features, or knowing that we'll have to rewrite them later?
# How much short term benefit do we get from the refactor, as well as long term?

Just like in the real world where debt is a useful financial tool, sometimes we need to live with technical debt because we chose other tradeoffs.  But to choose wisely we should investigate what we get on both sides of that trade as much as we can.

So, Sylvain is right; I'm not saying let's never do it, but I am saying that if we can't realize a short term win as well then I think we should put this back on the shelf for another release.

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