Cache Usage
Settings for the individual cache types can be specified in the category Automation Engine Management, Processes & Usage sub-page. For details, see Setting Advanced Options. Refer to Cache in the Administration perspective to obtain current information about the cache.
This page includes the following:
General Information
Each work process has its own cache. Only the actually used memory is allocated, and the cache size indicates the limit of each WP's cache. If new entries are stored in the cache when the limit has been reached, a background reorganization process is triggered which removes those entries from the cache which were longest unused. This procedure continues until the used memory is below the specified maximum value again. Each cache has its on refresh control to always keep it up to date. Hence, manual control is not necessary.
The Administration perspective shows the cache workload/utilization of the primary work process. If the workload of all work processes is equally distributed, however, the values obtained from the primary work process also apply to the other work processes. The utilization/hit ratio is recorded in the log file whenever the caches change or the work process ends. The workload/hit ratio of all work processes can be controlled in this log file.
Important! When the parameter PrimaryMode= in the INI file of the Automation Engine's INI file is set to 1, the cache utilization of the PWP is not representative for other WPs. In this case, the PWP accepts PWP messages only. Therefore, the workload of all work processes including PWP is not equally distributed. For more information, see Automation Engine.
Cache Types
The cache is composed of the following types:
Script
When activating an object, the corresponding script is first searched in the cache. If it cannot be found there or if it has been modified since it has last been stored in the cache, it is read from the database and at the same time replaced in the cache.
Vara
The cache type Vara acts in the same way as the cache type Script. It contains the values of variables.
MQMEM
The memory that the system requires for interrupting a transaction is stored in the database table MQMEM, and in the cache. Such an interruption can happen if the execution of a script takes too long, for example. No database access is required if the interrupted transaction continues in the work process in which it was interrupted. Therefore, the size of the required cache depends on processing and configuration.
ODOC
This cache type contains GUI descriptions (XML) for the Automic Web Interface. The cache content is not replaced.
XREQ
This type includes special AE scripts for handling the GUI. They are precompiled when the work process is started and stored in the cache.
USER
The same rules apply as for the cache type Script. User data is stored in the cache. This is mainly important for the Automic Web Interface converting the User ID (USR_Idnr) to the name and department.
OBJECT_IDNR and OBJECT_NAME
This data is stored in the cache in order to facilitate the conversion of the object code (OH_Idnr) to the object name (OH_Name) and vice versa without directly accessing the database.
HACL
In this cache type, the records for agent authorizations to clients are buffered so that access authorizations can be checked without accessing the database being necessary. Data is not replaced. An access ratio below 100% just indicates that a non-existing access authorization was searched for.
Settings
This optimum size is checked through the Administration perspective and the cache hit ratio.
-
Script
Optimal size: Depends on the number of objects
Refresh control: Usage counters of the object (Header tab)
-
Vara
Optimal size: Depends on the number of objects
Refresh control: Usage counters of the object (Header tab)
-
MQMEM
Optimal size: Depends on the particular number of messages
Refresh control: None, as each entry is only used once
-
ODOC
Optimal size: Fixed value
Refresh control: None, as there are no changes
-
XREQ
Optimal size: Fixed value
The hit ratio is always 100%.
Refresh control: None, as there are no changes
-
USER
Optimal size: Depends on the particular number of users
Refresh control: Usage counter of the user
-
OBJECT_IDNR and OBJECT_NAME
Optimal size: Depends on the number of objects
Refresh control: The cache is automatically renewed in all work processes whenever objects are renamed.
-
HACL
Optimal size: Fixed value
Refresh control: The cache is automatically set invalid when host authorizations are modified and newly created during the first Usage
See also: