[
https://issues.apache.org/jira/browse/CASSANDRA-16078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272446#comment-17272446
]
Caleb Rackliffe commented on CASSANDRA-16078:
---------------------------------------------
I took the scenario [~dcapwell] ran and made a couple small adjustments:
1.) The {{disk_access_mode}} in the original test was {{mmap}}, and that
probably doesn't make sense with a 64 KB chunk size. That was changed to
{{mmap_index_only}}.
2.) The original test flushed the Memtable every 500 milliseconds, and I've
removed that behavior.
Also, for clarity, the {{tlp-stress}} run does pre-populate 500 (1000-row)
partitions before starting its warmup. Finally, the test outlined above was
running with the stress argument {{--rate 800}}, which I've either continued to
use or scaled down to 400 for single-node tests.
I was not able to find any meaningful regression around select latency between
3.0/3.11 and 4.0/trunk. For both single-node and six-node tests (w/ RF=3),
4.0/trunk actually produces a better mean latency and latencies up to at least
the 99.9th percentile. In the example below, {{cie-pushbutton-123}} is a 3.0
cluster (w/ CASSANDRA-8180 back-ported from 3.x) and {{cie-pushbutton-122}} is
a 4.0/trunk cluster:
!latency_selects_3_4.png!
This chart corresponds to the 6-node cluster comparison, but the single-node
case looks almost exactly the same, so I've omitted it for now. Flamegraphs
sampled from individual nodes are very similar between the versions.
[^async-profile-3.0.19-3.svg]
[^async-profile-4.0.0-3.svg]
The only minor oddity is 4.0/trunk spending a bit more time in {{SEPWorker}}
wait spins. Looking at the CPU usage, things are mostly idle, so before I move
to close this, a test with more realistic load might be appropriate...
> Performance regression for queries accessing multiple rows
> ----------------------------------------------------------
>
> Key: CASSANDRA-16078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16078
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: David Capwell
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: ClusteringSlicing.kt, async-profile-3.0.19-3.svg,
> async-profile-4.0.0-3.svg, image.png, latency_selects_3_4.png
>
>
> This is spin off from CASSANDRA-16036.
> In testing 4.0 relative to 3.0* I found that queries which accessed multiple
> rows to have a noticeable performance decrease; two queries were used in the
> test (more may be impacted, others might not): query partition (table has
> clustering keys) with LIMIT, and query clustering keys using IN clause.
> In the below graphs the green line is 3.0 and the other lines are 4.0 (with
> and without chunk cache)
> Partition with LIMIT
> !https://issues.apache.org/jira/secure/attachment/13009751/clustering-slice_latency_selects_baseline.png!
> !https://issues.apache.org/jira/secure/attachment/13009750/clustering-slice_latency_under90_selects_baseline.png!
> Cluster with IN clause
> !https://issues.apache.org/jira/secure/attachment/13009749/clustering-in-clause_latency_selects_baseline.png!
> !https://issues.apache.org/jira/secure/attachment/13009748/clustering-in-clause_latency_under90_selects_baseline.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
