Hi Rei, As you pointed out, table (column family) metric only tracks memtable and row cache update. Update is done through Mutation object that can have several column families at once. And the unit of commit log is Mutation, so we may first write commit log of several tables and then we update each table. We really can't mix commit log latency to table metric right now. So I would say it is intended design. Other things you can use are query tracing to track individual query performance and client request metrics for coordinator level metric.
Maybe we can improve things by adding metrics for Keyspace#apply(). We have Keyspace level write metric, but it is just an accumulation of all table level write metrics. Feel free to open JIRA at https://issues.apache.org/jira/browse/CASSANDRA for improvement request. On Fri, Feb 5, 2016 at 6:44 PM, 大平怜 <rei.oda...@gmail.com> wrote: > Hi, > > I noticed that the write latency metric includes only memtable and rowcache > updates, but not sync to a commitlog. I am looking at > ColumnFamilyStore.apply() and KeySpace.apply(). Is my understanding > correct? Is this an intended design? I guess sync to a commitlog is the > most time consuming operation during a write (especially when batch commit > is used). > > Appreciate any help. > > > Thanks, > Rei Odaira -- Yuki Morishita t:yukim (http://twitter.com/yukim)
