Eviction Policies

Introduction

FNZ Studio objects are stored in distributed maps and in a node’s local cache to allow faster access and to boost the performance of your application.

The objects created in a distributed map remain in that map. However, unused objects can be deleted to free some space in memory. Unused objects can either be deleted manually, or evicted automatically.
FNZ Studio provides you with configuration properties for controlling the eviction of some of the maps managed by the system.

This article provides recommended values to use for these eviction configuration properties. It covers:

  • Cluster Files
  • Cluster Log
  • Cluster Cache
  • Application Cache
  • Data Handles
  • Value Stores
WARNING! The following recommendations apply to standard usages of Appway. You may need to use different values if you are using special functionalities on your system. For example, if you have a process migration script accessing all of your Process Instances, the amount of memory consumed could be very large. In such cases, consider using different property values for your Value Store eviction policies. If you are uncertain, contact your assigned Solution Engineer.

Cluster Files

The FNZ Studio Cluster File service provides cluster-wide binary storage. The Cluster File objects are saved in FNZ Studio permanent storage (in a filesystem or database), and in the distributed map (memory).

Property Description
nm.cluster.eviction.clusterfiles.maxidle Sets the lifetime of a Cluster File in a distributed map, i.e. the maximum duration (in seconds) that a Cluster File object can exist in the distributed map without being read. Recommendation: Evict Cluster Files from memory if not accessed for at least one working day. nRecommended valuenm.cluster.eviction.clusterfiles.maxidle = 43200 (12 hours)

Cluster Log

The Cluster Log consolidates the logs from all FNZ Studio nodes. The Cluster Log is not persisted by default, and only stays in memory for a limited duration. The lifetime of a Cluster Log entry is defined using the following configuration properties:

Property Description
nm.cluster.log.eviction.ttl Sets the time to live (TTL) in seconds. Cluster log entries are evicted from the distributed maps when the TTL expires. The TTL of a log entry cannot be less than 900 seconds (15 minutes). The value 900 substitutes any non-null value lower than 900. nExample: For "nm.cluster.log.eviction.ttl = 300" (5 minutes), the time to live of the log entries is automatically adjusted to 15 minutes. Increase the TTL value to between 7200 and 10800 (2–3 hours) if you want to see more entries, but consider the impact on memory consumption. Recommended value nnm.cluster.log.eviction.ttl= 900
nm.cluster.log.eviction.maxidle Specifies the number of seconds after which a cluster log entry is deleted from the distributed map if not read. The default value ("0") can be used. In order to avoid flooding the system with too many log statements, the "chunkvolume" and "compactionvolume" configuration properties are used to control the amount of information created in the Cluster Log. nRecommended valuennm.cluster.log.eviction.maxidle= 0
nm.cluster.log.limit.chunkvolume The default — and recommended — value is 400000 bytes (~0.4 MB). If the total size of the collected log statements is larger than 0.4MB within an interval of 10 seconds, no more log entries are added to the cluster. nRecommended valuenm.cluster.log.limit.chunkvolume= 400000 (~0.4MB)
nm.cluster.log.limit.compactionvolume The recommended value is 4000000 bytes (~4MB). If the total size of the collected log statements is larger than 4MB within a 10-minute interval, no more log entries are added to the cluster. Set the property nm.cluster.log.clearonstartup to "true" to clear cluster logs on startup. nRecommended values nm.cluster.log.limit.compactionvolume = 4000000 (4MB)

Log Compaction Functionality

The log compaction functionality runs every 10 minutes, starting from minute '3' of every hour. The time to live of a log entry is therefore between TTL and TTL+10 because the time to live of a log entry is reset during the compaction operation.

Example: For nm.cluster.log.eviction.ttl = 900 (15 minutes), a log entry created at 09:59 am will be evicted from memory at 10:18am, 19 minutes later.

  • Creation time: 09:59 am
  • Calculated eviction time: 09:59 + 15 minutes => 10:14 am
  • Log compaction times: 10:03 am, 10:13 am, 10:23 am, 10:33 am etc.
  • New eviction time for the log entry: 10:03 am + 15 minutes => 10:18 am

Cluster Cache

The Cluster Cache entries are created with the FNZ Studio function ClusterCacheStore.

It is also possible to have Cluster Cache entries created by an extension. For example, SOAP errors generated by the WebServices extension are written in the Cluster Cache.

The following configuration properties control the lifetime of the cluster cache entries:

Property Description
nm.cluster.cache.ttl Specifies the default time to live of entries in the Cluster Cache. The value defined here is used only if no TTL is specified during the creation of the entry. It is recommended to set this default TTL to "0", and specify either a TTL or retention expression* during the creation of a cluster cache entry via script. nRecommended value nm.cluster.cache.ttl = 0 (never)

Application Cache

The Application Cache is local to each node and populated with the FNZ Studio function CacheStore.

You can specify a retention expression for the CacheStore function. The entry stays in the cache as long as the retention expression is true.

IMPORTANT! You must specify the retention expression when using the application cache!

The retention expression is an expression returning true as long as the object is valid. The implicit variable $insertTimestamp (Long, the time when the object was stored or updated in the cluster cache in milliseconds) can be used in the expression.

Property Description
nm.applicationcache.size Sets the maximum number of entries in the application cache. nRecommended value nm.applicationcache.size = 1000

Data Handles

The binary data used in Business Objects are stored in Data Handles.

For example, when an image is uploaded to a Resource Business Object, the binary content of the image is not stored directly in the Business Object itself. Instead, a Data Handle object containing the binary content is created. The Data Handle is then referenced from the parent Business Object by its ID.

The Data Handle objects are loaded into the distributed map when created. The life time of Data Handle objects in the distributed map (memory) is configured using the following configuration properties:

Property Description
nm.cluster.eviction.datahandles.maxidle Specifies the time after which the data handle entry is deleted from the distributed map if not accessed (in seconds). Keep the Data Handle entries in the distributed map for at least one working day. Recommended value nm.cluster.eviction.datahandles.maxidle = 43200 (12 hours)
nm.cluster.eviction.datahandles.maxsize Specifies the maximum number of data handle items to keep in the distributed maps memory. Recommended value nm.cluster.eviction.datahandles.maxsize = 0
Note: See Unused Data Handle Cleanup for information on removing unused Data Handles from the `datahandles` directory in the Cluster Storage.

Value Stores

Value Stores contain all the data managed in a Process Instance and are loaded in memory (distributed map). The life time of an entry in the map can be controlled with the following configuration property:

Property Description
|nm.cluster.eviction.valuestores.maxidle Defines the maximum time a Value Store entry stays in the distributed map without being read.
Note: Non-persisted Process Instances and Value Stores (e.g. the Portal Process) are never evicted and are available until they are deleted. Non-persisted Process Instances are automatically deleted when the session they are attached to expires or is invalidated.

The fact that transient Processes are excluded from eviction means that the maxidle time can be set to the time a user is actively working on a single Process Instance, e.g. 20 minutes. The Value Store is loaded only once, for the rest of the maxidle time, the data are fetched from the distributed map which improves performance. n Recommended value nm.cluster.eviction.valuestores.maxidle = 1200 (20 minutes)

In addition to the eviction property, the lifetime of entries in the Cluster near cache is controlled by the following configuration properties:

Important! Check the Near Cache Configuration for Value Stores before continuing with the recommendations shared below.
Property Description
nm.cluster.nearcache.valuestores.maxidle Defines the maximum idle time for a Value Store entry in the node near cache . This cache layer offers better performance than the distributed map layer, but memory consumption is very high. The recommendation is to use a "maxidle" value that is set to around the maximum time a user would spend working on a Process Instance - for example, "900" (15 minutes). n Recommended value nm.cluster.nearcache.valuestores.maxidle = 900 (15 minutes)
nm.cluster.nearcache.valuestores.maxsize Specifies the maximum number of Value Store entries to keep in the near cache. Because the number of Process Instances opened at any one time can vary greatly, it is recommended to allow an unlimited (maxsize = 0) number of items in the near cache. nRecommended valuenm.cluster.nearcache.valuestores.maxsize = 0 (unlimited)
nm.cluster.nearcache.valuestores.ttl Sets the time to live (TTL) of a Value Store entry in thenear cache (in seconds). n Every value store entry created in the near cache is invalidated after the TTL expires. nRecommended value n nm.cluster.nearcache.valuestores.ttl = 1200 (20 minutes)