Remote cache tuning configurations in HCL Cache

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.

cacheConfigs:
  baseCache:
    remoteCache:
      codec: compressing

Sharding

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 and clear shard operations in parallel. The thread pool size is configured with the numAsyncCacheOperationThreads 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 or clear 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 multiple invalidate 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.

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