anchor.diff:  The answer depends on what you do with it.
   Having two tiers is a bit slower on writing.
   It is also a bit slower on reading when the data is not found in the caching tier (on-heap).
  -However, it will be faster for an entry that is indeed found there.
  +However, it will be faster for an entry that is indeed found in a higher tier.
   
   So again, it depends.
   The more you follow the caching hypothesis that the same data is always reused (and so in the caching
  -tier), the more interesting having two tiers will be.
  +tier), the more interesting having two or more tiers will be. As a general rule of thumb, a tier that has a
  +hit ratio of 50% or less is going to slow down the cache. Either enlarge such tier or completely get rid of it.
   
   == Byte Sizing
   
  
positive.code: 
  == Allocation rate
  
  Ehcache won't allocate any object during a simple `get()`.
  However, keep in mind that your configuration might do so.
  
  For instance, let's say you define an expiry policy like this.
  
negative.code: This is because the expiration time of an entry is calculated and updated ony when the entry is inserted or updated in the cache.
  But it still requires an expiration check at access time.
  
  So you can expect a 2% drop in performance when using TTL.
  
  === Time to Idle
  
  