Thanks for the information, Yuki, OK, I understood that the write latency is basically a table metric, not a keyspace metric. Looks like the query tracing is for analyzing each individual request, but it provides exactly the breakdown I want.
Thanks for your help! Let me also think about opening a new request in JIRA.... Rei Odaira 2016-02-07 21:51 GMT-06:00 Yuki Morishita <mor.y...@gmail.com>: > 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) >
