If you use CacheBox (and if you use ColdBox to any extent, you do) it is important to inspect your cache performance from time to time. A poorly tuned cache can bring about unexpected performance issues when your application gets under load (such as the dog-pile effect).
Since CacheBox is a cache aggregator that means it has the ability to wrap up multiple caches from different sources under one API. By default, ColdBox configures two caches called "default" and "template", but you can create as many caches as you like. One of the excellent features of CacheBox as a cache aggregator is that you get consolidated statistics on all your caches in one place.
Those statistics are available programatically, but the easiest way to access them is via the web-based CacheBox debug panel. If you have debug mode turned on, it will show up at the bottom of the request. Even if debug mode is turned off, you can stil access the cache debug panel at any time by adding "?debugMode=1&debugPanel=cache" to the end of your URL.
<Click to enlarge>
There is a wealth of information on this screen including your JVM's memory usage. After selecting a specific cache from the drop down, you can see how many items are in that particular store as well as hit/miss ratios and eviction counts.
The first thing to look for is signs that your cache is filling up and running out of space. Compare the number of items in the store during a busy time to the maximum allowed and make sure you have some breathing room. Your number of hits should definitely be higher than your misses. Evictions happen when your cache is too full and has to expire items early to make room. If you are seeing a high number of evictions and the cache is too full, increase the maximum number of objects (contingent on free memory), limit how many items your application caches, or decrease the expiration time.
Remember, reaping runs every two minutes by default. (Reaping is what actually removed expired items from the cache to make room for new ones) Long expiration may allow you to reduce reaping frequency but short expiration times may require reaping to run more often. Just remember, reaping locks portions of the cache's object pool when it runs so keep that in mind if your cache is very large.
If you're using a soft-reference store in one of the ColdBox cache providers, watch out for garbage collections. Those happen if your heap gets so low on memory that the JVM started garbage collecting your cache items to free up space. If that is happening, increase your heap, decrease the number of items or the size of the items in the cache, or lower the free memory threshold so evictions run sooner.
Another thing to consider if you're using one of the ColdBox cache providers is which eviction policy to use. The eviction policy only kicks in when your cache is too full and items have to be kicked out prior to their normal expiration. It's up to you to decide which items are least likely to be needed again soon based on your app's usage patterns-- the Least Recently Used, or the Least Frequently Used, etc.
There's a lot to consider when it comes to tuning your caches. The best approach is making isolated changes, collecting data, performing analysis, and then repeating the cycle. A well-tuned cache is mostly hits with far fewer misses, and naturally cleans itself through regular expirations without having to evict or garbage collect.
More info here: http://wiki.coldbox.org/wiki/CacheBox.cfm
P.S. Remember, if you have more than one cache, they all need to be tuned separately.
Add Your Comment