Reads during a write still occur during a counter increment with CL ONE, but that latency is not counted in the request latency for the write. Your local node write latency of 45 microseconds is pretty quick. what is your timeout and the write request latency you see. In our deployment we had some issues and we could trace the timeouts to parnew gc collections which were quite frequent. You might just want to take a look there too.
On Sat, Dec 29, 2012 at 4:44 PM, André Cruz <andre.c...@co.sapo.pt> wrote: > Hello. > > I recently was having some timeout issues while updating counters and > turned on row cache for that particular CF. This is its stats: > > Column Family: UserQuotas > SSTable count: 3 > Space used (live): 2687239 > Space used (total): 2687239 > Number of Keys (estimate): 22912 > Memtable Columns Count: 25766 > Memtable Data Size: 180975 > Memtable Switch Count: 17 > Read Count: 356900 > Read Latency: 1.004 ms. > Write Count: 548996 > Write Latency: 0.045 ms. > Pending Tasks: 0 > Bloom Filter False Postives: 17 > Bloom Filter False Ratio: 0.00000 > Bloom Filter Space Used: 44232 > Compacted row minimum size: 125 > Compacted row maximum size: 770 > Compacted row mean size: 308 > > Since it is rather small I was hoping that it would eventually be all > cached, and the timeouts would go away. I'm updating the counters with a CL > of ONE, so I thought that the timeout would be caused by the read step and > the cache would help here. But I still get timeouts, and the cache hit rate > is rather low: > > Row Cache : size 1436291 (bytes), capacity 524288000 (bytes), > 125310 hits, 442760 requests, 0.247 recent hit rate, 0 save period in > seconds > > Am I assuming something wrong about the row cache? Isn't it updated when a > counter update occurs or is just invalidated? > > Best regards, > André Cruz
