What is the assessment of the effectiveness of including statistics in Guava Cache objects?

Question

Obviously, the correct answer is “check it out and find out,” but in the spirit of the Internet, I hope someone does the job for me.

I really like the Guava cache libraries for web services. However, their documents are rather vague in this matter.

recordStats
public CacheBuilder<K,V> recordStats()
Turn on CacheStats accumulation while the cache is running. Without this, Cache.stats() will return zero for all statistics. Please note that recording statistics requires that bookkeeping be performed with each operation and, thus, impose a penalty for performance when working in the cache.

WITH
12.0 (previously the statistics collection was automatic)

From JavaDocs for CacheBuilder.recordStats() .

I'm curious if the seriousness of the performance penalty is documented, compared, or ran by someone. I think that this should be quite insignificant, in the order of nanoseconds per operation. The cache operations themselves are already synchronized - reading is not blocked and is not blocked, but records really take locks, therefore, additional blocking or concurrency is not required to change statistics. This should limit it to a few additional increment operations to access the cache.

The other side is perhaps some punishment when calling Cache.stats() . I plan to submit persistent statistics through the Codahale MetricsRegistry and to the Graphite server. The net effect is that statistics will be periodically retrieved, so if there are any blocking actions when retrieving, this can be bad.

Answer 1

Let's look at the source code :

What happens when we call CacheBuilder.recordStats() ?

CacheBuilder defines a no-op StatsCounter implementation of NULL_STATS_COUNTER , and this is what is used by default. If you call .recordStats() , it is replaced with a SimpleStatsCounter in which there are six LongAddable (usually a LongAdder , but returns to AtomicLong if it cannot use LongAdder ) for each of the statistics it tracks.

Then what happens when we build Cache ?

For the standard LocalCache (this is what you get from CacheBuilder.build() or CacheBuilder.build(CacheLoader) ), it builds the instance of the desired StatsCounter during construction . Each Segment Cache likewise gets its own instance of the same type of StatsCounter . Other Cache implementations may choose SimpleStatsCounter if they so wish, or provide their own behavior (for example, a non-operational implementation).

And when do we use Cache ?

Each call in LocalCache that LocalCache one of the statistical calls calls the corresponding methods StatsCounter.record*() , which in turn causes an atomic increment or addition based on LongAddable . LongAdder documented much faster than AtomicLong , so, as you say, this should be barely noticeable. Although in the case of non-op StatsRecorder JIT can fully optimize record*() calls, which can be noticeable over time. But a decision not to track statistics on this basis would be premature optimization .

And finally, when do we get statistics?

When you call Cache.stats() StatsCounter for Cache and all its Segments are merged together into a new StatsCounter and the result is returned to you. This means that there will be minimal blocking; each field needs to be read only once, and there is no external synchronization or blocking. This means technically the condition of the race (the segment can be obtained in the middle through aggregation), but in practice it does not matter.

So, in the resume?

You should feel comfortable using CacheBuilder.recordStats() on any Cache you need to monitor, and calling Cache.stats() as often as it is useful. The memory overhead is approximately constant, the speed of the overhead is negligible (and faster than any similar monitoring that you are likely to implement), as well as the overhead of the Cache.stats() conflict.

Obviously, a dedicated thread that does nothing but call Cache.stats() in a loop will cause some controversy, but that would be stupid. Any type of periodic access will go unnoticed.