Introduction: Java Cache

From Resin 4.0 Wiki

(Difference between revisions)
Jump to: navigation, search
Line 60: Line 60:
  
 
== 20% miss, 100ms miss time, 1ms hit time ==
 
== 20% miss, 100ms miss time, 1ms hit time ==
 +
 +
[[File:Cache-20-miss-changes.png]]
  
 
<table border="1">
 
<table border="1">

Revision as of 00:00, 29 January 2012

Squirrel-48.png

Faster application performance is possible with Java caching by saving the results of long calculations and reducing database load. The Java caching API is being standardized with jcache. In combination with Java Dependency Injection (CDI), you can use caching in a completely standard fashion in the Resin Application Server. You'll typically want to look at caching when your application starts slowing down, or your database or other expensive resource starts getting overloaded. Caching is useful when you want to:

  • Improve latency
  • Reduce database load
  • Reduce CPU use

Contents

Cache Performance Benefits

Since reducing database load is a typical cache benefit, it's useful to create a micro-benchmark to see how a cache can help. This is just a simple test with mysql running on the same server and a trivial query. In other words, it's not trying to exaggerate the value of the cache, because almost any real cache use will have a longer "doLongCalculation" than this simple example, and therefore the cache will benefit even more.

The micro-benchmark has a simple jdbc query in the "doLongCalculation" method

"SELECT value FROM test WHERE id=?"

and then to get useful data, the call to "doStuff" is repeated 300k times and compared with the direct call to "doLongCalculation" 300k times.

Type Time requests per millisecond Mysql CPU
JDBC 30s 10.0 req/ms 35%
Cache 0.3s 1095 req/ms 0%

Even this simple test shows how caches can win. In this simple benchmark, the performance is significantly faster and saves the database load.

  • 10x faster
  • Remove Mysql load

To get more realistic numbers, you'll need to benchmark the difference on a full application. Micro-benchmarks like this are useful to explain concepts, but real benchmarks require testing against your own application, in combination with profiling. For example, Resin's simple profiling capabilities in the /resin-admin or with the pdf-report can get you quick and simple data in your application performance.

The Resin ClusterCache implementation

Since Resin's ClusterCache is a persistent cache, the entries you save will be stored to disk and recovered. This means you can store lots of data in the cache without worrying about running out of memory. (LocalCache is also a persistent cache.) If the memory becomes full, Resin will use the cache entries that are on disk. For performance, commonly-used items will remain in memory.

Cache Performance

t = p_miss * t_miss + (1 - p_miss) * t_hit

20% miss, 100ms miss time, 1ms hit time

Cache-20-miss-changes.png

Change Performance
no change 20.8ms
0.5ms hit time 20.4ms
10% miss rate 10.9ms
50ms miss time 10.8ms
disable cache 100ms

Miss Ratio

Cache-hit-graph.png

Personal tools
TOOLBOX
LANGUAGES