[
https://issues.apache.org/jira/browse/CASSANDRA-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285715#comment-14285715
]
Sylvain Lebresne commented on CASSANDRA-8437:
---------------------------------------------
I opened that ticket initially because I had missed that we were exposing the
ReadRepairMetrics, and that ticket was initially created to not forget to check
and add it if it was missing.
That said, I do think exposing digest mismatches as a ratio (of mismatches /
total read requests) would be more simply consumable. And Benjamin as a point
that we can't really directly compute this ratio from what we currently have,
because it happens that for {{IN}} queries, we count just 1 query in the read
count metric but as those are internally multiple queries, we could count
multiple mismatches (so in practice, if we were to use those 2 numbers, the
ratio could be > 1 which could be confusing to users). It's not a big deal, but
maybe it make sense to more directly expose that "digest mismatch" ratio?
Again, the goal is to be able to quickly answer "how often do my reads actually
do 2 round-trips internally"?
> Track digest mismatch ratio
> ---------------------------
>
> Key: CASSANDRA-8437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8437
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Benjamin Lerer
> Priority: Minor
> Fix For: 2.1.3
>
> Attachments: CASSANDRA-8437.txt
>
>
> I don't believe we track how often read results in a digest mismatch but we
> should since that could directly impact read performance in practice.
> Once we have that data, it might be that some workloads (write heavy most
> likely) ends up with enough mismatches that going to the data read is more
> efficient in practice. What we do about it it step 2 however, but getting the
> data is easy enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
