cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8520) Prototype thread per core
Date Mon, 05 Jan 2015 18:01:35 GMT

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

Mime
View raw message