Cache-Nutzung

Die Einstellungen zu den einzelnen Cache-Typen können in der Kategorie Automation Engine Verwaltung im Unterabschnitt Prozesse und Auslastung definiert werden.

Diese Seite beinhaltet Folgendes:

Allgemeine Informationen

Jeder Arbeitsprozess besitzt seinen eigenen Cache. Es wird nur der wirklich verwendete Speicher allokiert, die Cache-Größe gibt an, wie groß dieser maximal für jeden WP wachsen darf. Werden nach dem Erreichen der maximalen Größe neue Einträge im Cache abgelegt, so wird im Hintergrund eine Reorganisation angestoßen, die jene Einträge aus dem Cache entfernt, die am längsten nicht mehr benötigt wurden. Der Vorgang hält solange an, bis die Größe wieder unter den Maximalwert gefallen ist. Jeder Cache hat seine eigenen Aktualisierungssteuerung, damit er immer aktuell ist. Eine manuelle Steuerung ist somit nicht notwendig.

Die Administration-Perspektive zeigt die Cache-Auslastung/Verwendung des primären Arbeitsprozesses. Im Falle einer gleichmäßigen Auslastung gelten die Werte, die aus dem primären Arbeitsprozess gewonnen wurden, jedoch auch für die übrigen Arbeitsprozesse. Bei Änderungen der Caches bzw. beim Beenden des Arbeitsprozesses wird die Auslastung/Trefferrate in der Logdatei protokolliert. In dieser Logdatei kann auch die Auslastung/Trefferrate der anderen Arbeitsprozesse kontrolliert werden.

Wichtig! Wenn der Parameter PrimaryMode= in der INI-Datei der Automation Engine (siehe Automation Engine) auf 1 gesetzt ist, ist die Nutzung des PWP nicht repräsentativ für andere WPs. In diesem Fall akzeptiert der PWP nur PWP-Meldungen. Daher ist die Auslastung aller Arbeitsprozesse einschließlich PWP nicht gleichmäßig verteilt.

Cache-Typen

Der Cache besteht aus den folgenden Typen:

Script

Bei der Aktivierung eines Objekts wird zunächst das zugehörige Script im Cache gesucht. Ist es dort nicht gespeichert oder hat sich das Script seit dem Abspeichern im Cache geändert, wird es aus der Datenbank gelesen und gleichzeitig im Cache ersetzt.

Vara

Der Cache-Typ Vara agiert auf die gleiche Weise wie das Script des Cache-Typs. Es enthält die Werte der Variablen.

MQMEM

Wenn eine Transaktion unterbrochen wird, z. B. ein Script, wenn die Zeit abgelaufen ist oder durch das Script-Element, das verarbeitet werden soll, wird der erforderliche Speicherplatz in der Datenbanktabelle MQMEM und im Cache gespeichert. Wenn diese Transaktion in demselben Arbeitsprozess fortgesetzt wird (in dem er unterbrochen wurde), erfolgt kein Datenbankzugriff. Die Größe des benötigten Caches ist somit verarbeitungs- und konfigurationsabhängig.

ODOC

Dieser Cache-Typ enthält die GUI-Beschreibungen (XML) für das Automic Web Interface. Es findet hier kein Austausch des Cache-Inhaltes statt.

XREQ

Zu diesem Typ gehören spezielle AE-Scripts, die der GUI-Behandlung dienen. Diese werden beim Start des Arbeitsprozesses vorkompiliert und im Cache abgelegt.

USER

Hier verhält es sich genauso wie beim Cache-Typ Script. Es werden die Benutzerdaten im Cache abgelegt. Dies dient hauptsächlich dem Automic Web Interface für die Umwandlung der Benutzer-ID (USR_Idnr) in Name/Abteilung.

OBJECT_IDNR und OBJECT_NAME

Damit eine Umwandlung der Objektkennung (OH_Idnr) in den Objektnamen (OH_Name) bzw. umgekehrt erfolgen kann, ohne direkt auf die Datenbank zugreifen zu müssen, werden diese Daten im Cache gespeichert.

HACL

In diesem Cache-Typ werden die Datensätze für Agenten-Berechtigungen auf Mandanten zwischengespeichert, um die Zugriffsberechtigungen ohne Datenbankzugriffe überprüfen zu können. Hier werden die Daten nicht ausgetauscht. Eine Zugriffsrate unter 100% bedeutet lediglich, dass eine Zugriffsberechtigung gesucht wurde, die nicht existiert.

Einstellungen

Die Überprüfung der optimalen Größe erfolgt über die Administration-Perspektive und die Cache-Trefferrate.

  • Script

    Optimale Größe: Hängt von der Anzahl der Objekte ab

    Aktualisierungssteuerung: Nutzungszähler des Objekts (Registerkarte Header)

  • Vara

    Optimale Größe: Hängt von der Anzahl der Objekte ab

    Aktualisierungssteuerung: Nutzungszähler des Objekts (Registerkarte Header)

  • MQMEM

    Optimale Größe: Hängt von der jeweiligen Anzahl der Meldungen ab

    Aktualisierungssteuerung: Keine, da jeder Eintrag nur einmal verwendet wird

  • ODOC

    Optimale Größe: Fester Wert

    Aktualisierungssteuerung: Keine, da es keine Änderungen gibt

  • XREQ

    Optimale Größe: Fester Wert

    Die Trefferrate ist immer 100 %.

    Aktualisierungssteuerung: Keine, da es keine Änderungen gibt

  • USER

    Optimale Größe: Hängt von der jeweiligen Anzahl der Benutzer ab

    Aktualisierungssteuerung: Nutzungszähler des Benutzers

  • OBJECT_IDNR und OBJECT_NAME

    Optimale Größe: Hängt von der Anzahl der Objekte ab

    Aktualisierungssteuerung: Der Cache wird beim Umbenennen von Objekten automatisch über alle Arbeitsprozesse hinweg erneuert.

  • HACL

    Optimale Größe: Fester Wert

    Aktualisierungssteuerung: Der Cache wird nach einer Änderung der Hostberechtigungen automatisch auf ungültig gesetzt und bei der ersten Verwendung neu aufgebaut.

Siehe auch: