Caching in Deploy
- Deploy 23.1 and later lets you cache frequently accessed data for better performance and reduced latency.
- Caching is disabled by default, and you must enable it to start caching the data.
- You can enable caching as part of Deploy installation or upgrade.
- If you want to enable caching as part of installation, make sure to run the
run.sh -setupcommand to have the Deploy central configuration files (such asdeploy-caches.yaml,deploy-cluster.yaml, anddeploy-task.yaml) generated so that you can set up the required keys in those files for enabling caching. - After vetting out a handful of caching solutions, Digital.ai recommends Infinispan 14.0.2 for use with Deploy.
- Digital.ai Deploy uses Cache-Aside (Lazy Loading) cache pattern to ensure that data is cached only when necessary and JCache (JSR-107) API as an abstraction over the cache.
Note: This feature is only available for Deploy on JVMs and Docker-based installations but not for Operator-based sites.
Benefits of Caching
Comprehensive testing was carried out (with multiple datasets and common deployment scenarios) at Digital.ai to assess the effect of caching on the overall performance of the Digital.ai Deploy's deployment APIs. A comparison of the performance test data from sites with and without caching was also carried out.
Though the performance improvement was not that significant during initial deployments—as the cache was being built—we were able to witness significant performance improvements (by about 20-30 percentage as illustrated in the following table) during subsequent update deployments when the cache was fully built and utilized.
| API | Performance Improvement % |
|---|---|
/xldeploy/deployment/prepare/update | 35% |
/xldeploy/deployment/prepare/deployeds | 26% |
/xldeploy/deployment/validate | 45% |
| Total | 33% |
With caching enabled, we noticed a significant performance improvement with the following APIs.
/xldeploy/deployment/prepare/initial/xldeploy/deployment/prepare/update/xldeploy/deployment/prepare/deployeds/xldeploy/deployment/validate/xldeploy/deployment/prepare/undeploy
Who Should Use Caching?
During testing, we used two datasets:
- First dataset:
Target environment containing
- Over 1300 deployed applications
- 5253 containers and Source applications with
- 7 packages
- Each package containing one deployable
- Second dataset:
Target environment containing
- Over 20 applications
- 20 containers Source applications with
- 3 packages
- Each package containing 50 deployables
Having covered a wide range of datasets, we can assure you that caching offers significant performance improvements with slow running deployment planning APIs in almost every setup.
There are multiple subjective criteria such as the number of deployed applications, number of containers, number of packages, and so on that can impact the deployment performance and can be considered for using cache. As a rule of thumb, if you notice a latency of about 10 to 15 seconds with the deployment planning APIs, we recommend that you try the caching feature.
Getting the Best Performance Using Caching
Performance improvement with caching depends on getting a high Cache hit %. Cache Expiration Lifespan determines how often the data stored in the cache is cleared and directly influences the Cache hit % and performance. In general, setting a high expiration lifespan ensures more cached data and in turn, higher cache hits. We recommend tweaking the Cache Expiration Lifespan based on your setup and arriving at the best value based on the change in performance. See Configure Cache Expiration Lifespan for details.
Types of Cache
There are two types of cache: app caches and system caches.The app caches include the following CI caches:
| Cache | Description |
|---|---|
| CI_PK_CACHE | Cache for CIs by primary keys |
| CI_PATH_CACHE | Cache for CIs by their paths |
| CI_PROPERTIES_CACHE | Cache for CI properties |
| LICENSE_CI_COUNT | Cache for license restricted CI counts |
The system cache consists of jython-script-cache-configuration. By default, both the caches are set to false.
Here's a YAML example with app cache and system cache settings configured:
- app caches can be embedded for single node instance and standalone for multi-node instances.
- system caches can operate through embedded caching.
By caching the CI data in the Deployment flow, these caches help in improving the performance during the Deployment planning phase.
Cache Setup Options
You can enable caching in both single node and cluster (Active-Active) setups.
- Caching for a single node Deploy server—this setup consists of a single node Deploy server. In this setup, the embedded cache server runs in the same process as Deploy.
- Caching for Deploy cluster setup—the Active-Active cluster setup supports high availability. You must set up a separate Infinispan cache server for read, write, and evict operations in the Active-Active cluster setup.
Follow the instructions in these topics to enable and configure caching: