[
https://issues.apache.org/jira/browse/CASSANDRA-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253954#comment-14253954
]
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: 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)
