cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8520) Prototype thread per core
Date Fri, 19 Dec 2014 20:17:14 GMT


Benedict commented on CASSANDRA-8520:

FTR, I meant storage _format_ not storage _engine_. Though no doubt both will help.

The crux of the _near_term performance improvement here is removing a ~fixed burden of synchronization.
Being ~fixed, if we have significant cost reductions to make and are targeting a proportional
yield, we should reduce those other costs before measuring the benefit here. 

i.e., if this is currently 30% of time (say), but we can shave 90% off of it, that is only
a ~27% improvement. If we can shave 80% off the remaining 80% first, then this improvement
is ~150%.

> Prototype thread per core
> -------------------------
>                 Key: CASSANDRA-8520
>                 URL:
>             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

View raw message