cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8520) Prototype thread per core
Date Fri, 19 Dec 2014 19:41:14 GMT

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

Aleksey Yeschenko commented on CASSANDRA-8520:
----------------------------------------------

Sure. But we can't blindly commit to a huge rewrite of all the things, unless we know the
effect of the change is dramatic.

It's just not worth it from risk perspective. Can't throw away proven and working code for
some uncertain benefit.

bq. An initial goal might be benchmarking in-memory read workloads that don't touch memtables.

I hope you mean sstables here, not memetables, because otherwise it would be totally useless.

> 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