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 19:28:14 GMT


Benedict commented on CASSANDRA-8520:

bq. If we can't get a big win (say at least 2x)

We should be careful when setting up the goalposts in advance. If we see a dramatic shift
in location of bottleneck without a dramatic shift in total performance, that simply means
it's not _yet_ worth it. A change like this will have to go hand-in-hand with other changes
to make the most of it: new memtables, new commit log, faster storage format, in process page
cache, AIO for disk operations, ... we can strip even a lot of this out to see what the dividends
will be, of course, but in many ways this is much more of an opening of the doors to many
improvements in performance and reliability.

What's the maximal scope for proving/disproving this as a way forwards? If we rule it out
without taking it actually quite far, we may simply be premature. Alternatively if we can
see modest improvements with only a small exploration of the potential it might be enough
to suggest commital is a good thing. Unfortunately we just cannot explore many of these improvements
without thread-per-core.

An initial goal might be benchmarking in-memory read workloads that don't touch memtables,
so we can isolate as much of the system as possible. We will still want to explore some of
the natural optimisations we can make, and probably shutdown many of the other things the
system is doing to ensure we get a good picture of yield.

> 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