Service caching
Caching improves decision evaluation performance and reduces latency by storing data retrieved from services for faster retrieval on subsequent service requests.
A service is a good candidate for caching if service response values don’t change very often.
How service caching works
When the decision engine requests information from a service, it caches the service response if the data has not already been cached. On subsequent service requests, instead of invoking the service again, the decision engine uses the cached data until the cache expires.
The cached value is used as long as none of the values defined in Service Settings have changed. The decision service invokes the service and caches the service response under a new key when a value in the service request changes, such as when there’s a new parameter in the request body, or an attribute value is resolving differently.
To prevent changes in request header values from invalidating an HTTP service response cache, you can exclude such headers from the cache key. For more information, see step 8c in Connecting a service.
PingAuthorize maintains the service response in the cache for the period of time that you define in the Time to live setting for a service
|
Cache entries are stored in memory and do not persist during a restart or outage unless you have defined your own data store. |
Service caching configuration
You can configure cache settings for individual services when you add or edit a service in the Trust Framework. For more information, see Connecting a service.
If you’ve already set up external attribute caching in PingAuthorize and enable caching for a service:
-
Attributes are cached in an external Redis instance.
-
Services are cached with the same configuration object used for external attribute caches and are also cached locally in memory.
You cannot configure external caching just for services. If you are not seeing cache hits in the external cache instance, this might be because the cache entry is also stored locally. Storing cache entries both locally and externally is unique to services. Attributes configured with external caching are not stored locally.
Service caching behavior
Unlike attribute caching, which uses a one-level approach where cache entries are stored and retrieved from the single configured cache type, service caching uses a two-level approach to improve performance and minimize redundancy. For example, if you configure an external Redis cache, a local cache acts as the first-level cache, and the Redis instance acts as the second-level cache.
When making a call to a service, the decision engine attempts to load the first-level cache entry, and if the entry cannot be found, an attempt is made to load the second-level cache. If neither attempt succeeds, the decision engine makes a call to the service itself. If the second-level cache entry is unreachable, the first-level cache entry is stored for a maximum of 2 minutes.
You cannot clear the cache manually.
|
Service cache settings in PingAuthorize override any cache control headers in the HTTP response. This can result in:
|