[ https://issues.apache.org/jira/browse/CASSANDRA-10585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008933#comment-15008933 ]
Carl Yeksigian commented on CASSANDRA-10585: -------------------------------------------- While the version for 2.1 is fine, for 2.2 and 3.0, I don't think we should switch to {{ExponentiallyDecayingReservoir}}; the reasoning behind us using {{EstimatedHistogram}} is discussed in CASSANDRA-5657. I'd like to either come up with a way to either estimate the statistic trying to be calculated here, or extend {{EstimatedHistogram}} to properly capture a 0 value. I think we can approximate this by using the {{RowCacheHit}}/{{RowCacheMiss}} metrics; that would mean {{SSTablesPerReadHistogram}} is only captured on {{RowCacheMiss}}, so the new metric might be {noformat} (RowCacheMiss/(RowCacheHit + RowCacheMiss)) * SSTablesPerRead {noformat} Do either of those seem feasible, [~isburmistrov]? > SSTablesPerReadHistogram seems wrong when row cache hit happend > --------------------------------------------------------------- > > Key: CASSANDRA-10585 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10585 > Project: Cassandra > Issue Type: Bug > Reporter: Ivan Burmistrov > Priority: Minor > Fix For: 2.1.x, 2.2.x, 3.0.x > > Attachments: SSTablePerReadHistogram_RowCache-cassandra-2_1.patch, > SSTablePerReadHistogram_RowCache-cassandra-2_2.patch, > SSTablePerReadHistogram_RowCache-cassandra-3_0.patch > > > SSTablePerReadHistogram metric now not considers case when row has been read > from row cache. > And so, this metric will have big values even almost all requests processed > by row cache (and without touching SSTables, of course). > So, it seems that correct behavior is to consider that if we read row from > row cache then we read zero SSTables by this request. > The patch at the attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)