Cache Utilization

This page includes the following:

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 is continued until the used memory could have been reduced below the specified maximum value. 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 PrimaryMode= parameter in the INI file of the Automation Engine (see Automation Engine) 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.

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

If a transaction is interrupted - for example, a script when the time has expired or caused by the script element that is to be processed - the required memory is stored in the database table MQMEM and in the cache. If this transaction is then continued in the same work process (in which it has been interrupted), no database access is made. Hence, 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.

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: Utilization counters of the object (Header tab)

• Vara

  Optimal size: Depends on the number of objects

  Refresh control: Utilization 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: Utilization 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 utilization