1                     Themenübersicht

In diesem Dokument wird die Funktionsweise des Shared Caches im ERP-System näher betrachtet. Die Konfiguration des Shared Caches beeinflusst die Leistungsfähigkeit des gesamten Systems.

2                     Zielgruppe

• Systemadministratoren
• Entwickler

3              Voraussetzungen

Voraussetzung sind Kenntnisse über die Programmierung und Architektur des ERP-Systems. Kenntnisse über dessen Administration sind hilfreich.

4              Begriffsbestimmung

Transaction Cache

Der Transaction Cache ist ein lokaler Speicherbereich, in den Änderungen innerhalb einer Transaktion zwischengespeichert werden. Er entsteht beim Erzeugen einer neuen Top-Level-Transaktion. Die im Transaction Cache gespeicherten Änderungen werden beim Commit der Top-Level-Transaktion ausschließlich vollständig persistent. Jede Top-Level-Transaktion hat ihren eigenen Transaction Cache.

Shared Cache

Der Shared Cache ist ein Zwischenspeicher für bereits im Hauptspeicher geladene Business-Object-Instanzen. Er wird gemeinsam von allen Sessions eines ERP-System-Application-Servers genutzt. Dadurch werden identische Datenbankzugriffe vermieden.

5                     Beschreibung

Die folgende Abbildung zeigt das Zusammenspiel von Transaction Cache, Shared Cache und Datenbank.

Übersicht über die Architektur der Caches

Der Shared Cache dient der Zwischenspeicherung von bereits geladenen Business-Object-Instanzen im Hauptspeicher. Der Zugriff auf ein Business Object in der Datenbank benötigt deutlich mehr Zeit als der Zugriff auf ein Business Object im Shared Cache. Daher werden einmal von der Datenbank gelesene Business Objects eine gewisse Zeit lang im Shared Cache zwischengespeichert. Lesende Zugriffe zum Laden von Business Objects laufen generell über den Shared Cache.

Der Shared Cache speichert nur die einfachen Zugriffe zum Laden von Business Objects zwischen, nicht aber die Ergebnisse komplexer Anfragen. Der Zeitaufwand zum Ausführen von komplexen Anfragen, wie das Suchen, ist unabhängig vom Shared Cache.

Jeder ERP-System-Application-Server hat einen eigenen Shared Cache, auf den alle Sessions gemeinsam zugreifen. Wenn ein Anwendungsprogramm eine Änderung an der Datenbank vornimmt, dann werden zunächst alle Änderungen im Transaction Cache gesammelt und dann gemeinsam in die Datenbank und ggf. den Shared Cache übernommen.

Für neue Application-Server legt das System automatisch die Größe des Shared Caches fest, wenn Sie nichts manuell dazu festgelegt haben. Für die manuelle Festlegung steht Ihnen die Anwendung „Application-Server-Einstellungen“ zur Verfügung.

Je größer der Shared Cache ist, desto höher ist die Wahrscheinlichkeit, dass Leseanforderungen aus dem Shared Cache beantwortet werden können. Je größer der Shared Cache ist, desto weniger Hauptspeicher verbleibt für die Sessions, d. h. damit können weniger Benutzer auf dem Application-Server arbeiten.

Der Shared Cache ist in mehrere Cache-Partitionen unterteilt. Jede der Cache-Partitionen hat eine beschränkte Größe. Die Anzahl und Größe dieser Cache-Partitionen können Sie frei konfigurieren. Jedes Business Object wird abhängig von der Datenart und der Datenbank in einer der Cache-Partitionen aufgenommen.

Beispiel für die Aufteilung des Shared Caches in Cache-Partitionen

Die Aufteilung des Shared Caches in mehrere Cache-Partitionen spiegelt die unterschiedliche Verwendung der Business Objects wider. Stammdaten werden beispielsweise sehr häufig wiederholt gelesen, während sie sich nur sehr wenig ändern. Bewegungsdaten werden selten wiederholt gelesen, sie ändern sich sehr häufig. Wenn nun Stamm- und Bewegungsdaten in einem Cache aufgenommen werden, dann werden die Stammdaten durch die Bewegungsdaten verdrängt und müssen dadurch unnötig häufig nachgelesen werden. Die Bewegungsdaten profitieren jedoch durch den großen Cache nicht sonderlich, da diese nur selten wiederverwendet werden. Durch die getrennte Behandlung von Stamm- und Bewegungsdaten kann die Trefferrate des Shared Caches erhöht und damit die Leistungsfähigkeit des Gesamtsystems gesteigert werden.

5.1               Einstellungen zum Business Object

Der Entwickler legt fest, welche Daten ein Business Object enthält und wie dieses Business Object im Shared Cache behandelt werden soll. Diese Einstellungen hängen direkt mit der Verwendung des Business Objects in den Anwendungen zusammen.

5.1.1          Cache-Strategie

Jedes Business Object wird gemäß einer bestimmten Strategie im Shared Cache behandelt. Pro Business Object und Datenbank können Sie folgende Einstellungen zum „Caching“ (Zwischenspeichern) vornehmen:

Schalten Sie das Caching nur in Sonderfällen ab, zum Beispiel wenn Folgendes zutrifft:

• Objekte werden nur geschrieben und selten gelesen
• sehr viele Objekte bestehen und diese werden nur selten mehrfach gelesen

Alle Instanzen sollten nur zwischengespeichert werden, wenn das System häufig versucht, Objekte mit einem ungültigen Schlüssel zu lesen, und die Anzahl der Objekte klein ist. Objekte, von denen alle Instanzen zwischengespeichert werden, werden nicht in Cache-Partitionen aufgenommen.

Die LRU-Strategie stellt den Standardfall dar. Jedes mit der LRU-Strategie gekennzeichnete Objekt wird in einer Cache-Partition gespeichert. Cache-Partitionen sind Speicherbereiche begrenzter Größe. Die Zuordnung von Objekten zu Cache-Partitionen hängt von der Datenbank und von der Datenart ab.

5.1.2          Datenart

Die Datenart des Business Objects unterscheidet im Wesentlichen die Änderungsfrequenz. Die unterschiedlichen Änderungsfrequenzen eines Business Objects sind der wichtigste Grund für die Partitionierung des Caches.

Die Datenart ist ein wesentliches Entscheidungsmerkmal, in welcher Cache-Partition im Shared Cache ein Business Object aufgenommen wird.

5.2               Cache-Partitionen

Einerseits wird durch die Aufteilung des Shared Caches in mehrere getrennte Cache-Partitionen verhindert, dass eine Massen-Datenverarbeitung mit Bewegungsdaten alle anderen Cache-Inhalte verdrängt. Andererseits wird durch eine zu starke Partitionierung der verfügbare Hauptspeicher nicht optimal genutzt. Die geeignete Aufteilung des Hauptspeichers in verschiedene Cache-Partitionen hängt vom Anwendungsfall ab.

Wenn beispielsweise sehr viele Partner oder Artikel bestehen, dann wird ggf. eine größere Cache-Partition für die Stammdaten benötigt. Wenn die Nutzungswahrscheinlichkeit der Stammdaten sehr unterschiedlich ist, z. B. einige Artikel werden sehr häufig verwendet, andere fast nie, dann muss die Cache-Partition wiederum nicht so groß gewählt werden.

Wenn beispielsweise Aufträge sehr viele Positionen (z. B. > 1000) haben und viele Benutzer parallel Aufträge bearbeiten, dann sollte die Cache-Partition mit den Bewegungsdaten eher größer gewählt werden, da die Anwendungen zur Auftragsbearbeitung davon profitieren, wenn alle Positionen im Shared Cache gespeichert werden können.

Da weitere komplexe Abhängigkeiten zwischen dem konkreten Anwendungsfall und der Größe bzw. Aufteilung des Shared Caches liegen können, empfiehlt sich beim Aufsetzen eines neuen Systems, dieses System zunächst mit Standardeinstellungen zu betreiben. Bei größeren Systemen empfiehlt sich, diese Einstellungen mithilfe von Lasttests zu optimieren. Bei kleineren oder bereits im Betrieb befindlichen Systemen kann die Optimierung der Einstellungen auch während des Betriebs stattfinden.

Die Größen der Cache-Partitionen können Sie mit der Anwendung „Application-Server-Einstellungen“ verändern.

5.2.1          Standardaufteilung der Cache-Partitionen

Für einen neuen ERP-System-Application-Server erzeugt das System automatisch die Partitionen und vergibt die geeigneten Größen, wenn Sie nichts über die Anwendung „Application-Server-Einstellungen“ festlegen. Sie können die Größen ändern, um die Leistungsfähigkeit des Application-Servers zu erhöhen.

Nachfolgend finden Sie beispielhaft die automatisch ermittelten Partitionsgrößen in Abhängigkeit des Hauptspeichers des Application-Servers (Heap):

Die Zuordnung eines Business Objects zu einer Cache-Partition ist abhängig von Datenart und Datenbank. Die folgende Tabelle stellt den Bezug zu den Cache-Partitionen in der Standardeinstellung her:

5.2.2          Vorgehensweise: Cache-Partitionen festlegen

Mithilfe der Anwendung „Application-Server-Einstellungen“ können Sie die Cache-Partitionen und deren Größen für einen Application-Server festlegen.

Anleitung

1. Öffnen Sie die Anwendung „Application-Server-Einstellungen“
2. Wechseln Sie auf die Ansicht „Application-Server“.
3. Erfassen Sie den Namen des Application-Servers im Feld „Application-Server“, zu dem Sie Einstellungen vornehmen möchten.
4. Drücken Sie „Neu“ in der Standard-Symbolleiste.
   • Die Anwendung wechselt in den Neu-Modus.
5. Drücken Sie den Button „Neu“ unter dem Karteireiter „Partitionen“.
   • Eine neue Tabellenzeile wird erzeugt.
6. Erfassen Sie in der neuen Tabellenzeile in der Spalte „Partition“ eine Identifikation für die Stammdaten-Partition, z. B. „Stammdaten“ oder „Master“.

Hinweis:

Beachten Sie bei der Vergabe der Identifikation, dass ein sprechender Text sinnvoll, aber nicht in andere Oberflächensprachen übersetzbar ist.

7. Erfassen Sie in derselben Zeile in der Spalte „Größe“ die Größe der Stammdaten-Partition in Megabyte (MB).
8. Wiederholen Sie den Vorgang für die Bewegungsdaten-Partition: Vergeben Sie eine Identifikation, z. B. „Bewegungsdaten“ oder „Transaction“, und erfassen Sie die Größe der Bewegungsdaten-Partition in Megabyte (MB).

Hinweis:

Beachten Sie bei der Vergabe der Identifikation, dass ein sprechender Text sinnvoll, aber nicht in andere Oberflächensprachen übersetzbar ist.

9. Wechseln Sie auf den Karteireiter „Zuordnungen“.
   • Unter dem Karteireiter „Zuordnungen“ werden alle zugeordneten Datenbanken aufgeführt.
10. Wählen Sie für alle Datenbanken in den Spalten für die Datenarten „Konfigurations-Stammdaten“ und „Stammdaten“ die zuvor unter dem Karteireiter „Partitionen“ erfasste Cache-Partition für die Stammdaten.
11. Wählen Sie für alle Datenbanken in den Spalten für die Datenarten „Bewegungsdaten“ und „Temporär“ die zuvor unter dem Karteireiter „Partitionen“ erfasste Cache-Partition für die Bewegungsdaten.
12. Drücken Sie den Button „Speichern“ in der Standard-Symbolleiste.
    • Die Einstellungen werden für den Application-Server gespeichert.

5.2.3          Optimierung der Cache-Partitionen

Eine optimierte Aufteilung der Cache-Partitionen hängt sehr stark vom Lastprofil des Systems ab. Wenn eine OLTP-Datenbank beispielsweise sehr viele Artikel oder Partner enthält oder sehr viele Nebensprachen konfiguriert sind, dann benötigt dieses System eine große Stammdaten-Partition. Wenn in einer OLTP-Datenbank hingegen Aufträge mit sehr vielen Positionen erfasst sind, dann kann eine große Bewegungsdaten-Partition die Antwortzeiten der Auftragserfassung verbessern.

Weiterhin beeinflusst der Verwendungszweck des Application-Servers die Größe der Cache-Partitionen. Bei einem Application-Server mit unbeschränktem ODBC-Zugriff sollte die Stammdaten-Partition nicht unter 64 MB sein. Der unbeschränkte ODBC-Zugriff bedeutet, dass Verknüpfungen mit Stammdaten in einigen Fällen über den Persistenzdienst, d. h. über den Shared Cache, aufgelöst werden. Wenn der Shared Cache so groß ist, dass dieser alle für den ODBC-Zugriff relevanten Stammdaten enthält, verkürzen sich die Zeiten zum Ausgeben von Belegen und Berichten.

Wir empfehlen, die Cache-Hit-Rate und die Partitionsbelegung (Füllungsgrad) der Cache-Partitionen in regelmäßigen Abständen bzw. nach einem Lasttest zu kontrollieren. Wenn die Cache-Hit-Rate in einer Partition zu klein ist, dann können nicht ausreichend viele Objektzugriffe durch den Shared Cache beantwortet werden. In diesem Fall muss auf die deutlich langsamere Datenbank zugegriffen werden. Das kann einen negativen Effekt auf die Leistungsfähigkeit des Gesamtsystems haben. Folgende Ursachen können zu einer kleinen Cache-Hit-Rate führen:

• Eine Anwendung greift auf sehr viele Daten zu (z. B. ein Verarbeitungsauftrag).
• Eine Anwendung ist schlecht programmiert und versucht Objekte zu laden, zu denen keine Objekte existieren.
• Die Cache-Partition ist zu klein.

Eine Partitionsbelegung von unter 99 % bedeutet, dass der Application-Server nicht die maximale Cache-Partitionsgröße ausgeschöpft hat. Das kann die folgenden Gründe haben:

• Der Application-Server läuft noch nicht lange genug.
• Auf dem Application-Server wurde noch nicht gearbeitet.
• Die Cache-Partition ist zu groß.

Die Cache-Hit-Rate und die Partitionsbelegung einer Partition werden in der Anwendung „Systemcockpit“ für einen laufenden Application-Server angezeigt.

Vorgehensweise: Cache-Hit-Rate und Belegung einer Partition abfragen

1. Öffnen Sie die Anwendung „Systemcockpit“.
2. Wählen Sie im Feld „Typ“ den Typ „Application-Server“.
3. Erfassen Sie im Feld „Name“ die Identifikation des Application-Servers, zu dem Sie Daten abfragen möchten, und drücken Sie in der Standard-Symbolleiste auf den Button „Aktualisieren“.
   • Die Daten zum Application-Server werden geöffnet.
4. Wechseln Sie auf den Karteireiter „Partitionen“.
5. In der Liste unter dem Karteireiter „Partitionen“ werden u. a. die Hit-Rate und die Partitionsbelegung in Prozent angezeigt.

Die Stammdaten-Partition sollte eine Cache-Hit-Rate von über 95 % haben. Wenn die Cache-Hit-Rate unter 95 % liegt, dann ist das ein Warnzeichen. Wenn die Cache-Hit-Rate über längere Zeit unter 95 % liegt oder ein akutes Leistungsfähigkeitsproblem vorliegt, dann erhöhen Sie in diesem Fall die Größe der Stammdaten-Partition.

Bei der Bewegungsdaten-Partition ist die Cache-Hit-Rate abhängig von der verwendeten Funktionalität. Die Angabe von konkreten Grenzwerten ist daher nicht allgemein möglich. Ein Warnzeichen für eine zu kleine Bewegungs-Partition ist, wenn die Anwendungen zur Auftragsbearbeitung eine lange Wartezeit bei der Bearbeitung haben.

Je nach den verwendeten Anwendungen kann eine niedrige Cache-Hit-Rate in der Bewegungsdaten-Partition sogar der Normalfall sein. Wenn beispielsweise jeder Datensatz nur ein einziges Mal geöffnet wird, dann ist die Cache-Hit-Rate bei 0 %. Diese niedrige Cache-Hit-Rate ist jedoch kein Zeichen für eine schlechte Leistungsfähigkeit des Application-Servers, sondern ein Zeichen für die gute Programmierung der Anwendung. Diese Aussage lässt sich nicht verallgemeinern, soll aber verdeutlichen, dass bei Bewegungsdaten die Cache-Hit-Rate nicht unbedingt in Verbindung mit der Leistungsfähigkeit des Application-Servers steht.

Wenn nach 15 Minuten auf einem Application-Sever mit Last die Partitionsbelegung einer Cache-Partition nicht bei 99 % liegt, dann ist diese Partition voraussichtlich zu groß gewählt. Wenn nach 2 Stunden die Partition immer noch einen Belegungsgrad von unter 99 % hat, dann ist die Cache-Partition zu groß. Kontrollieren Sie nach dem Verkleinern der Cache-Partition unbedingt die Cache-Hit-Rate. Wenn die Cache-Hit-Rate deutlich kleiner wird, dann müssen Sie die Cache-Partition wieder vergrößern.

Nach einer Änderung der Cache-Partitionen sollten Sie kontrollieren, ob die Änderung den gewünschten Erfolg hat. Wenn beispielsweise eine Vergrößerung des Shared Caches keinen positiven Effekt hat, dann sollte der Shared Cache wieder verkleinert werden, damit mehr Speicher für die Anwendungen übrig bleibt.