The values that indicate a well-tuned cache vary by the nature of the caches, and a host of deployment-specific factors. Key things to check for include whether the cache limit has been reached and the hits:misses ratio.

The table below lists statistics for several Hyperic caches and, in the "Comments" column, a possible interpretation of the data.

Table 1. Cache Statistics Interpretation

Cache

Size

Hits

Misses

Limit

Comments

Agent.findByAgentToken605

605

26010977

605

5000

This cache appears healthy. It contains relatively static objects. The cache has not filled up, and the number of misses is equal to the number of hits, so misses occurred only on the first request of each object.

org.hyperic.hq.events. server.session.Alert

70526

48049

71274

100000

This cache appears healthy. It contains a type that is likely to become stale relatively quickly, so aging out is appropriate. Although there are more misses than hits, the low number of objects in memory, compared to the cache limit, indicates a low level of server activity since the last restart.

org.hyperic.hq.events.server.session.AlertDefinition

66287

44385

66340

100000

This cache appears healthy. It contains a relatively static type, so it is appropriate that the objects do not age out. The cache is not filled up, and the number of misses is very close to the number of hits, indicating most misses occurred on the first request of the object.

Measurement.findByTemplate ForInstance

10000

6766

25772

10000

This cache appears less healthy. It has reached its maximum size, and the hit ratio is around 20-25%. Ideally, the number of misses should peak at about the maximum size of the cache. Increasing the cache limit would probably improve Hyperic performance.

Note that the generalization that misses should peak around the limit of the cache does not apply to the UpdateTimestampsCache and the PermissionCache caches, which contain types that are invalidated frequently.