[
https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851901#comment-17851901
]
Stefan Miklosovic edited comment on CASSANDRA-19676 at 6/4/24 6:01 AM:
-----------------------------------------------------------------------
5.0 build
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/4364/workflows/09dc15ac-31a1-41bf-90d4-319c0650304b]
basically the same tests as in trunk failed.
I have not tried to dig into that yet. On the other hand, they are "just"
timeouts.
was (Author: smiklosovic):
5.0 build
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/4364/workflows/09dc15ac-31a1-41bf-90d4-319c0650304b]
basically the same tests as in trunk failed
> 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.x
>
> Attachments: after.png, image-2024-06-02-17-25-25-071.png
>
> Time Spent: 0.5h
> 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 2000k --maxwlat 10 -r 0.1 --rate 5000
> --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]
