[ https://issues.apache.org/jira/browse/CASSANDRA-19676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852104#comment-17852104 ]
Brandon Williams commented on CASSANDRA-19676: ---------------------------------------------- I ran a 5.0 build [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1650/workflows/35a6dff8-a82b-4313-9040-0bee58106498] and got similar results, so I ran a 5.0 baseline [here|https://app.circleci.com/pipelines/github/driftx/cassandra/1651/workflows/738d1c92-0ffe-45e7-8ad4-f2646170ba76] and it looks like these tests were recently broken before this patch. > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org