Testing the Cache
The main benefit of a Hibernate second-level cache is raising performance by decreasing the number of times an application accesses the database. To gauge the level of database offloading provided by the Enterprise Ehcache for Hibernate second-level cache, look for these benefits:
Server CPU offload – The CPU load on the database server should decrease.
•
Lower latency – The latency for returning data should decrease.
•
Higher Transactions per second (TPS) – The TPS rate should increase.
•
More concurrency – The number of threads that can access data should increase.
•
The number of threads that can simultaneously access the distributed second-level cache can be scaled up more easily and efficiently than database connections, which generally are limited by the size of the connection pool.
You should record measurements for all of these factors before enabling the Enterprise Ehcache for Hibernate second-level cache to create a benchmark against which you can assess the impact of using the cache. You should also record measurements for all of these factors before tuning the cache to gauge the impact of any tuning changes you make.
Another important test in addition to performance testing is verifying that the expected data is being loaded.
For example, loading one entity can result in multiple cache entries. One approach to tracking cache operations is to set Hibernate cache logging to "debug" in log4j.properties:
log4j.logger.org.hibernate.cache=debug
This level of logging should not be used during performance testing.
NOTE: Optimizing Cache Performance Before doing performance testing, you should read through the rest of this document to learn about optimizing cache performance. Some performance optimization can be done ahead of time, while some may require testing to reveal its applicability.
When using a testing framework, ensure that the framework does not cause a performance bottleneck and skew results.
Optimizing the Cache Size
Caches that get too large may become inefficient and suffer from performance degradation. A growing rate of flushing and faulting is an indication of a cache that's become too large and should be pruned.
Explicit sizing of caches is discussed in the Ehcache documentation.
Expiration Parameters
Expiration is important because it forces unneeded data to be automatically evicted when accessed or when constraints require resources to be freed. The most important parameters for tuning cache size and cache Testing and Tuning Enterprise Ehcache for Hibernate
performance in general are the following:
timeToIdle (TTI) – This parameter controls how long an entity can remain in the cache without being accessed at least once. TTI is reset each time an entity is accessed. Use TTI to evict little-used entities to shrink the cache or make room for more frequently used entities. Adjust the TTI up if the faulting rate (data faulted in from the database) seems too high, and lower it if flushing (data cleared from the cache) seems too high.
•
timeToLive (TTL) – This parameter controls how long an entity can remain in the cache,
regardless of how often it is used (it is never overridden by TTI). Use TTL to prevent the cache from holding stale data. As entities are evicted by TTL, fresh versions are cached the next time they are accessed.
•
TTI and TTL are set in seconds. Other options for limiting the life of data and the size of caches are discussed in the Ehcache documentation.
How to Set Expiration Parameters
You can set expiration parameters in these ways:
In ehcache.xml – Configuration file for Enterprise Ehcache for Hibernate with properties for controlling expiration on a per-cache basis. See the Ehcache documentation for more information.
•
In the Terracotta Developer Console – The GUI for Hibernate second-level cache allows you to apply real-time values to expiration parameters and export a configuration file. For more information, see Enterprise Ehcache for Hibernate Applications.
•
Programmatically – When creating caches programmatically.
•
After setting expiration parameters, be sure to test the effect on performance (see Testing the Cache).
Reducing the Cache Miss Rate
The cache miss rate is a measure of requests that the cache could not meet. Each miss can lead to a fault which requires a database query. (However, misses and faults are not one-to-one since a query can return results that satisfy more than one miss.) A high or growing cache miss rate indicates the cache should be optimized.
To lower the miss rate, adjust for regions containing entities with high access rates to evict less frequently.
This keeps popular entities in the cache for longer periods of time. You should adjust expiration parameter values incrementally and carefully observe the effect on the cache miss rate. For example, TTI and TTL that are set too high can introduce other drawbacks, such as stale data or overly large caches.
Examinator Example
Examinator, the Terracotta reference application that uses Enterprise Ehcache for Hibernate to implement the second-level cache, supports thousands of concurrent user sessions. This web-based test-taking application caches exams and must have TTI and TTL properly tuned to prevent unnecessarily large data caches and stale exam pages.
The following sections detail how certain cached Examinator data is configured for second-level caching.
Included are snippets from the Enterprise Ehcache for Hibernate configuration file (see Cache Configuration File).
Optimizing the Cache Size
User Roles
The data defining user roles has the following characteristics:
Never changes – User roles are fixed (read only).
•
Accessed frequently – Each user session must have a user role.
•
Therefore, user roles are cached and never evicted (TTI=0, TTL=0). In general, read-only data that is used frequently and never grows stale should be cached continuously.
<cache name="org.terracotta.reference.exam.domain.UserRole"
User data, which includes the user entity and its role, is useful only while the user is active. This data has the following characteristics:
Access is unpredictable – User interaction with the application is unpredictable and can be sporadic.
•
Lifetime is unpredictable – The data is useful as long as the user session has activity. Only when the user becomes inactive are the associated entities idle.
•
Therefore, these entities should have a short idle time of two minutes (TTI=120) to allow data associated with inactive user sessions to be evicted. However, there should never be evicted based on a hard lifetime
(TTL=0), thus allowing the associated entities to be cached indefinitely as long as TTI is reset by activity.
<cache name="org.terracotta.reference.exam.domain.User"
Exam data is includes the actual exams being taken by users. It has the following characteristics:
Rarely changes – There is the potential for exam questions to be changed in the database, but this happens infrequently.
•
Optimizing the Cache Size
Data set is large – There can be any number of exams, and not all of them can be cached due to limitations on the size of the cache.
•
Since there can be many different exams, and the potential exists for a cached exam to become stale, cached exams should be periodically evicted based on lack of access (TTI=3600) and to ensure they are up-to-date (TTL=86400).
<terracotta/>
</cache>