For the record, I'm not certain there *is* a great deal of value in this. The read latency metrics are expected to vary a great deal, since the entire IO subsystem is involved.
Writes, however, go straight to a memtable. They only block on IO if we exceed our commit log flush bandwidth for an extended period of time. We already have a metric for tracking this: CommitLog.WaitingOnCommit. I'm not saying there won't be any latency distribution, but it is unlikely to be terribly interesting in very many situations. I can't off the top of my head think of a good reason to consult this metric, that couldn't better be answered elsewhere. On 13 February 2018 at 19:18, Sumanth Pasupuleti < spasupul...@netflix.com.invalid> wrote: > Thanks Kurt and Chris for your valuable inputs. Created > https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start > working on this. > > Thanks, > Sumanth > > On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink <clohf...@apple.com> wrote: > > > It would be good to have it. Its not that its not there because its > > difficult or anything. I think its more that the read latency metric was > > needed for speculative retry so it was added but the write side wasn't > > needed for that feature so wasn't added at same time. It would be very > > useful in determining the table that the coordinator writes are slow to. > > > > Chris > > > > > On Feb 11, 2018, at 10:33 PM, kurt greaves <k...@instaclustr.com> > wrote: > > > > > > I've tried to search around for a reason for this in the past and > haven't > > > found one. I don't think it's a bad idea. Would be a helpful metric to > > > diagnose internode networking issues - although I'll note that the read > > > metric will also achieve this assuming you have enough reads to get > some > > > useful information out of it. > > > > > > On 9 February 2018 at 17:43, Sumanth Pasupuleti < > > > sumanth.pasupuleti...@gmail.com> wrote: > > > > > >> There is an existing CoordinatorReadLatency table metric. I am looking > > to > > >> add CoordinatorWriteLatency table metric - however, before I attempt a > > shot > > >> at it, would like to know if anyone has context around why we > currently > > do > > >> not have such metric (while we have the read metric) - if someone has > > >> already attempted and realized its a bad idea for some reason. > > >> > > >> Thanks, > > >> Sumanth > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
