[
https://issues.apache.org/jira/browse/CASSANDRA-10993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-10993:
------------------------------------
Attachment: tpc-benchmarks.txt
I have a first round of benchmark results of CASSANDRA-10993-WIP vs trunk (at
{{007a3f57a328eaace19daca54901ccb70522d89f}}). I'm still working on rebasing
the RxJava work for comparison.
This setup is testing a single C* node with RF=1. All reads are served from a
memtable.
The data was populated with a cassandra-stress write with the following options:
{noformat}
write n=2000000 -pop seq=1..100000
{noformat}
Reads were performed with six different stress clients (on separate servers)
simultaneously. All of the stress clients executed the following:
{noformat}
read n=10000000 no-warmup -rate threads=950 -pop seq=1..10000
{noformat}
I tested with different numbers of threads, and 950 seemed to maximize the
throughput for both 10993 and trunk.
Here's a quick summary of the results:
* 10993 achieved 220236 reads/sec, trunk achieved 198576 reads/sec.
* 10993 median latency is quite a bit lower (~13ms vs ~20ms)
* 10993 95th latency is a little higher (~82ms vs 60ms)
* 10993 99th and 99.9th latencies are roughly double that of trunk
I did test setting {{concurrent_reads}} > {{native_transport_max_threads}} on
trunk as recommended in CASSANDRA-10528, but it had no significant effect on
performance.
The detailed stress results for these runs can be found in the attached
{{tpc-benchmarks.txt}} file.
> Make read and write requests paths fully non-blocking, eliminate related
> stages
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-10993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10993
> Project: Cassandra
> Issue Type: Sub-task
> Components: Coordination, Local Write-Read Paths
> Reporter: Aleksey Yeschenko
> Assignee: Tyler Hobbs
> Fix For: 3.x
>
> Attachments: 10993-reads-no-evloop-integration-six-node-stress.svg,
> tpc-benchmarks.txt
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne]
> (CASSANDRA-5239), and others, convert read and write request paths to be
> fully non-blocking, to enable the eventual transition from SEDA to TPC
> (CASSANDRA-10989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}},
> and {{READ_REPAIR}} stages, move read and write execution directly to Netty
> context.
> For lack of decent async I/O options on Linux, we’ll still have to retain an
> extra thread pool for serving read requests for data not residing in our page
> cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit FSMs
> and chained futures. Fibers would be the third, and easiest option, but
> aren’t feasible in Java without resorting to direct bytecode manipulation
> (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - three
> in Java and one in C++ - and I’m not convinced that it’s the optimal (or
> sane) choice for representing our complex logic - think 2i quorum read
> requests with timeouts at all levels, read repair (blocking and
> non-blocking), and speculative retries in the mix, {{SERIAL}} reads and
> writes.
> I’m currently leaning towards an implementation based on explicit FSMs, and
> intend to provide a prototype - soonish - for comparison with
> {{CompletableFuture}}-like variants.
> Either way the transition is a relatively boring straightforward refactoring.
> There are, however, some extension points on both write and read paths that
> we do not control:
> - authorisation implementations will have to be non-blocking. We have control
> over built-in ones, but for any custom implementation we will have to execute
> them in a separate thread pool
> - 2i hooks on the write path will need to be non-blocking
> - any trigger implementations will not be allowed to block
> - UDFs and UDAs
> We are further limited by API compatibility restrictions in the 3.x line,
> forbidding us to alter, or add any non-{{default}} interface methods to those
> extension points, so these pose a problem.
> Depending on logistics, expecting to get this done in time for 3.4 or 3.6
> feature release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
