Remote cache tuning configurations in HCL Cache
This document describes cache level tuning configurations for remote caches.
See Cache Configuration for details about how these settings can be applied to custom or default caches.
Compression
HCL Cache provides the option to use a compression algorithm, LZ4, on the cache key values. Caches with large keys, such as JSP caching in baseCache can benefit from compression. Compression reduces the size of the keys in Redis, and reduces network traffic, but it can increase CPU usage on the client containers. You might see no benefit from enabling compression on caches with small keys.
codec: compressing
under the remoteCache
element for the desired
cache.cacheConfigs:
baseCache:
remoteCache:
codec: compressing
Sharding
shards
configuration under the
remoteCache
element for a particular cache, with a value higher than
one.cacheConfigs:
baseCache:
remoteCache:
shards: 3
{cache-demoqalive-baseCache}-invalidation
{cache-demoqalive-baseCache:s=0}-(dep|data)
{cache-demoqalive-baseCache:s=1}-(dep|data)
{cache-demoqalive-baseCache:s=2}-(dep|data)
Because each shard is assigned a unique hash slot, sharding is typically used with Redis
Clustering, since it allows each shard or cache segment to be handled by a different Redis
node. Sharding can be helpful for caches that might overwhelm a single Redis node, either
due to their memory footprint, or the amount of load/operations they generate.
baseCache
is an example of a cache that might benefit from sharding.
In a Redis cluster environment, the slot assignment is done considering the namespace, cache name and shard number. It is not guaranteed that the shards will be evenly distributed across the Redis nodes, but this issue can be overcome by increasing the number of shards or by using slot migration.
- Impact of sharding on cache operations
-
Get Put Invalidate Clear A hashing algorithm is applied over the cache-id to select the shard that the cache entry should be retrieved from. Sharding has negligible impact on "get" operations. A hashing algorithm is applied over the cache-id to select the shard that the cache entry will be assigned to. Sharding has negligible impact on "put" operations. Invalidations must be executed against all shards. This is done in parallel. A clear
operation must be executed against all shards. This is done in parallel.
- Parallel processing of invalidate and clear operations
- The HCL Cache uses a thread pool to perform
invalidate
andclear
shard operations in parallel. The thread pool size is configured with thenumAsyncCacheOperationThreads
setting, which is configured at the top level of the YAML configuration:numAsyncCacheOperationThreads: -1 cacheConfig: ...
numAsyncCacheOperationThreads
defaults to-1
, which translates to the maximum number of shards configured for any cache.When an
invalidate
orclear
operation is executed on a sharded cache, the HCL Cache attempts to use the threadpool to execute in parallel. If the thread pool has no queued threads, all shards will be executed concurrently. If the thread pool is in use, and there are queued tasks, the threadpool is not used and each shard is processed sequentially. This is to manage a potential case where multipleinvalidate
operations are executed concurrently on a sharded cache, which might require a large number of threads to be active.
Inactivity
Inactivity is available from HCL Commerce Version 9.1.10. It is disabled by default. The configuration of inactivity enables the HCL Cache to track and evict entries that are not seeing reuse. By removing idle entries before their expiry time, the total cache memory used is reduced, which makes the cache run more efficiently.
Because the tracking of inactive entries adds a processing cost, inactivity is not currently enabled by default. Instead, it is enabled for selected default caches, and can be enabled for other default or custom caches.
enabled: true
and
specify a number of minutes using the inactivityMins
configuration.
cacheConfigs:
baseCache:
remoteCache:
onlineInactiveEntriesMaintenance:
enabled: true
inactivityMins: 30
See Cache Maintenance for details on how inactivity maintenance is performed, and can be monitored and tuned.
- Use of inactivity with local caches
-
Local caches support inactivity at the cache entry level. Inactivity can be configured using the cachespec.xml, or programatically with the DistributedMap interface. Inactivity set by DynaCache is used for local caching only and does not impact the inactivity process of the remote cache, which must be enabled independently.
- Inactivity vs Low Memory Maintenance
-
Production environments generate large amounts of cache. Certain caches, such as users or "searchTerm", can grow unbounded and eventually fill up the remote cache memory (maxmemory). When Redis memory usage is near the limit, Low Memory Maintenance triggers to maintain the usage under 100%. The use of Inactivity Maintenance can eliminate or reduce the processing done for Low Memory Maintenance. The use of Inactivity Maintenance is more efficient as follows:
- Inactivity Maintenance runs continuously, while Low Memory Maintenance only triggers when the memory is nearly full. Keeping a smaller memory footprint allows Redis to run more efficiently, including high availability operations such as persistence and recovery.
- Inactivity Maintenance runs from all containers, while Low Memory Mainteance is active from only a single container at any one time.
- Low Memory Maintenance must remove a percentage of the cache, and it does so by selecting entries that are sooner to be expired, even if they may have high reuse. However, Inactivity Maintenance only removes inactive entries, helping to retain other high reuse entries.
- Inactivity and skip-remote cache directive
-
The HCL Cache has special configurations called Cache directives that are used with cache entries to skip local or remote caching. Caches that enable local and remote caching, and deal with entries that might not see reuse, may benefit from these configurations. Examples include REST calls that specify searchTerm, faceting and pagination. Caches that create many cache entries that are not reused can be inefficient. Disabling remote caching for those caches can help reduce remote cache memory footprint. From HCL Commerce Version 9.1.10, you can choose to allow these entries in the remote cache, while relying on Inactivity processing to remove inactive entries.
- QueryApp REST Caching for searchTerm
-
The QueryApp container implements the skip-remote directive for certain "searchTerm" caches in cachespec.xml. If you enable Inactivity for
baseCache
, consider allowing these caches to use the remote cache, by customizing the cachespec.xml file to remove the following snippets:<component id="DC_HclCacheSkipRemote" type="attribute"> <required>true</required> </component>
Optimizations for Cache Clear Operations
Remote cache clear
operations work by scanning the Redis database and
deleting all the keys that match the cache prefix (e.g.
{cache-demoqalive-baseCache}-*
). This algorithm is most efficient with
large caches, or with caches that account for a large percentage of the total keys.
When clearing a small cache, the algorithm must still scan the whole database for matching
keys. As the cache clear
operation is non-blocking, the scanning might be
slow and require many calls to the Redis server.
For small caches, it is more efficient to use the invalidate
logic. The
invalidate
logic processes each cache entry and its dependency IDs, but
avoids the complete database scan by using the dependency
ID set. To perform a clear
, the invalidate
logic
is executed with the &ALL&
implicit dependency ID, which is
associated with all the keys in the cache.
The HCL Cache is configured to use the invalidate
algorithm for cache clears with the setting
smallCacheClearOptimizationMaximumSize
, which is enabled by default with
a value of 50000
.
smallCacheClearOptimizationMaximumSize
is available since 9.1.6.
cacheConfigs:
baseCache:
remoteCache:
smallCacheClearOptimizationMaximumSize: 50000