[
https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852839#comment-17852839
]
Jon Haddad commented on CASSANDRA-19676:
----------------------------------------
It would be great to see if there was an impact to latency and throughput from
the test, as well as system metrics. That combination should always be
referenced for performance patches.
easy-cass-lab can provision lab environments for these type of tests and makes
it pretty easy to use the free tier of AxonOps with it. It includes a ton of
diagnostic tooling including async-profiler and bcc-tools to perform detailed
analysis that I like to see on performance tests.
> Stream processing for StorageProxy::updateCoordinatorWriteLatencyTableMetric
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-19676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19676
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
> Reporter: Sam Lightfoot
> Assignee: Sam Lightfoot
> Priority: Normal
> Fix For: 5.0-beta2, 5.1
>
> Attachments: after.png, image-2024-06-02-17-25-25-071.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> On profiling a write-heavy workload (90% writes) using easy-cass-stress, it
> became very clear StorageProxy::updateCoordinatorWriteLatencyTableMetric was
> a hot path that ~15% of the CPU cycles of
> ModificationStatement::executeWithoutCondition were taken up by (see attached
> async-profiler image).
> We should convert this stream to a simple for loop, as has been discussed
> recently on the mail list.
> easy-cass-stress command:
> $ bin/easy-cass-stress run KeyValue -n 10m --maxwlat 10 -r 0.1 --rate 20000
> --compaction twcs
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
