[
https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599150#comment-17599150
]
Chris Lohfink commented on CASSANDRA-8612:
------------------------------------------
This PR doesnt impact latencies so I dont believe it would be too jarring. Its
really sstables per read and `nodetool profileload` that this effects.
I do think a single "this is the actual read latencies" metric of some sort
would lead to less confusion but should be a new one for upgrade simplicity.
Adding a LatencyMetrics with both the range and partition latencies as children
would then merge them without extra impact to the read path.
> Read metrics should be updated on all types of reads
> ----------------------------------------------------
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
> Reporter: Chris Lohfink
> Assignee: Dean Z
> Priority: Low
> Labels: lhf, metrics
> Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch,
> 0002-Add-more-read-metrics-into-PartitionRangeReadCommand.patch
>
>
> Metrics like "sstables per read" are not updated on a range slice. Although
> separating things out for each type of read could make sense like we do for
> latencies, only exposing the metrics for one type can be a little confusing
> when people do a query and see nothing increases. I think its sufficient to
> use the same metrics for all reads.
--
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
