Ehcache (2.9.x)-Configuration guide, configuring Storage Tiers

About Storage Tiers

Ehcache have three storage tiers, summarized here:

• Memory Store–heap memory that holds a copy of the hottest subset of data from the Off-heap store. Subject to Java GC.
• Off-heap store–limited in size is only by available RAM. Not subject to Java GC. Can store serialized data only. Provides overflow capacity to the memory store.
• Disk store–backs up in-memory data and provides overflow capacity to the other tiers. Can store serialized data only.

This document defines the standalone storage tiers and their suitable element types and then details of the configuration for Each storage tier.

Before running in production, it's strongly recommended, the tiers with the actual amount of data you expect To use in production. For information on sizing the tiers, refer to sizing Storage.

Configuring Memory Store

The memory store is always enabled and exists in heap memory. For the best performance, allot as much heap memory as possible without triggering garbage collection (GC) pauses, and use The Off-heap store to the data, cannot fit in heap (without causing GC pauses).

The memory store has the following characteristics:

• Accepts all data, whether serializable or not
• Fastest storage option
• Thread safe for use by multiple concurrent threads

The memory store is the top tier and are automatically used by Ehcache to store the data hotset because it is the faste St store. It requires no special configuration to enable, and its overall size was taken from the Java heap size. Since it exists in the heap, it's limited by Java GC constraints.

memory use, spooling, and expiry strategy in the memory Store

All caches specify their maximum in-memory size, in terms of the number of elements, at configuration time.

When an element was added to a cache and it goes beyond its maximum memory size, an existing element was either deleted, if Overflow is isn't enabled, or evaluated for spooling to another tier, if overflow is enabled. The overflow options are overflowtooffheap and <persistence> (Disk store).

If overflow is enabled, a check for expiry are carried out. If It is expired it is deleted; If not it is spooled. The eviction of a item from the memory store was based on the optionalmemorystoreevictionpolicy attr Ibute specified in the configuration file. Legal values is LRU (default), LFU and FIFO:

• Least Recently Used (LRU) -LRU is the default setting. The last-used timestamp is updated if an element was put into the cache or an element was retrieved from the cache with a Get call.
• Least frequently Used (LFU) -for each get call on the element, the number of hits is updated. When a puts call was made for a new element (and assuming, the max limit is reached for the memory store) the element wi Th least number of hits, the less frequently used element, is evicted.

• First In first out (FIFO) -elements is evicted in the same order as they come in. When a puts call was made for a new element (and assuming the max limit is reached for the memory store) the element th At were placed first (first-in) in the store are the candidate for eviction (first-out).

For all the eviction policies there is also putquiet () and Getquiet () methods which do not update t He last used timestamp.

When there was a get () or a getquiet () on an element, it was checked for expiry. If expired, it is removed and null is returned. Note that at any point in time there would usually is some expired elements in the cache. Memory sizing of an application must all-in-account, the maximum size of each cache.

Tip: calculateinmemorysize () is a convenient method that can provide an estimate of the size (in bytes) The memory store. It returns the serialized size of the cache, providing a rough estimate. Do not use the This method in production as it is have a negative effect on performance.

An alternative was to has an expiry thread. This is a trade-off between lower memory usage and short locking periods and CPU utilization. The design is in favor of the latter. For those concerned with memory use, simply reduce the tier size. For more information, refer to Sizing Storage Tiers.

Configuring Disk Store

The disk store provides a Thread-safe disk-spooling facility that can being used for either additional storage or persisting Data through system restarts.

This section describes local disk usage. You can find additional information about configuring the disk store in configuring Restartability and persistence .

Serialization

Only data This is Serializable can placed in the disk store. Writes to and from the disk use ObjectInputStream and the Java serialization mechanism. Any non-serializable data overflowing to the disk store are removed and a notserializableexception is thrown.

Serialization speed was affected by the size of the objects being serialized and their type. It has been found that:

• The serialization time for a Java object consisting of a large Map of String arrays is 126ms, where the serialized size W As 349,225 bytes.
• The serialization time for a byte[] is 7ms, where the serialized size was 310,232 bytes.

Byte arrays is faster to serialize, making them a better choice for increasing disk-store performance.

Configuring the Disk Store

Disk stores is configured on a per CacheManager basis. If One or more caches requires a disk store but none are configured, a default directory is used and a warning message is L Ogged to encourage explicit configuration of the disk store path.

Configuring a disk store is optional. If all caches with only memory and then there are no need to configure a disk store. This simplifies configuration, and uses fewer threads. This also makes it unnecessary-configure multiple disk store paths when multiple cachemanagers is being used.

Both disk store options are available:

• Temporary store (localtempswap)
• Persistent Store (localrestartable)

Localtempswap

The localtempswap Persistence strategy allows the memory store to overflow to disk when it becomes full. This option makes the disk a temporary store because overflow data does not survive restarts or failures. When the node was restarted, any existing data on disk was cleared because it was not designed to be reloaded.

If the disk store path is not specified, a default path is used, and the default would be auto-resolved in the case of a CO Nflict with another cachemanager.

The localtempswap disk Store creates a data file for each cache on startup called "<cache_name>.data". /c3>

Localrestartable

This option implements a restartable store for all in-memory data. After any restart, the data set was automatically reloaded from disk to the In-memory stores.

The path to the directory where any required disk files would be created are configured with the <diskStore> sub-e Lement of the Ehcache configuration. In order to use the Restartable store, a unique and explicitly specified path is required.

The diskstore Configuration Element

Files is created in the directory specified by the <diskStore> configuration element. The <diskStore> element has one attribute called path.

<path= "/path/to/store/data"/>

Legal values for the path attribute is legal file system paths. For example, for Unix:

/home/application/cache

The following system properties is also legal, in which case they is translated:

• User.home-user ' s home directory
• User.dir-user ' s current working directory
• Java.io.tmpdir-default Temp file path
• Ehcache.disk.store.dir-a system property would normally specify on the command line-for example, Java-dehcache.disk . Store.dir=/u01/myapp/diskdir.

Subdirectories can specified below the system property, for example:

User.dir/one

To programmatically set a disk store path:

New diskstoreconfiguration (); Diskstoreconfiguration.setpath ("/my/path/dir"//   New cachemanager (configuration);

Note: A CacheManager ' s disk store path cannot be changed once it's set in configuration. If the disk store path is changed, the CacheManager must are recycled for the new path to take effect.

Disk Store Expiry and eviction

Expired elements is eventually evicted to free up disk space. The element is also removed from the in-memory index of elements.

One thread per cache is used to remove expired elements. The optional attribute Diskexpirythreadintervalseconds sets the interval between runs of the expiry thread.

Important: Setting diskexpirythreadintervalseconds to a low value can cause excessive disk-store locking and high CPU utilization. The default value is seconds.

If a cache ' s disk store has a limited size, Elements'll be evicted from the disk store when it exceeds this limit. The LFU algorithm is used for these evictions. It is not configurable or changeable.

Note: With the LOCALTEMPSWAP strategy, your can use Maxentrieslocaldisk or maxbyteslocaldisk at either the Cache O R CacheManager level to control the size of the disk tier.

Turning off Disk Stores

To turn off disk store path creation, comment out the ' diskstore element in Ehcache.xml.

The default Ehcache configuration, Ehcache-failsafe.xml, uses a disk store. To avoid use of a disk store, specify a custom Ehcache.xml with theDiskstore Element commented out.

Ehcache (2.9.x)-Configuration guide, configuring Storage Tiers