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: == Serialization
  
  Off-heap, disk and clustering need to serialize keys and values before storing them.
  By default, custom super-fast serializers are used for `Long`, `Integer`, `Character`, `Double`, `Float`, `byte[]` and
  `String` objects.
  A slightly faster, customized Java serialization is used for other object types.
  It is well-known for not being the fastest thing around.
  Ehcache uses it because it is supported out of the box.
  However, you can increase performance by providing your own serializers.
  
  == Copier
  
  By default, on-heap storage stores the entries by reference.
  You might want to use a copier to store entries by value for whatever reason.
  Out of the box, Ehcache bundles a copier that makes use of its serialization mechanism:
  `org.ehcache.impl.copy.SerializingCopier`.
  This can be much slower so watch out.
  
  == Loader-Writer
  