Caching

Das Caching in den jadice-Produkten ist ein integraler Bestandteil um das Rendering und andere rechen- und zeit-intensive Vorgänge zu beschleunigen und damit eine flüssige Arbeitsweise mit den Produkten zu ermöglichen.

Die Eigenschaften und Arbeitsweise eines Caches hängt von seiner Implementierung und Konfiguration ab. jadice bietet zwei Cache Varianten, den CompositeKeyCache und den LRUCache an. CompositeKeyCache ist als Standard Cache voreingestellt.

Verwaltet werden die Caches über den CacheManager. Dort lässt sich der Standardcache setzen und erfragen.

Caches

In den jadice utils gibt es zwei Caches: Den LRUCache und den CompositeKeyCache.

Das Owner-Konzept

Das Owner-Konzept ist ein spezieller Mechanismus, um das Caching zu optimieren. Dabei stellt der Owner ein Objekt dar, das eines oder mehrere davon zwingend abhängige Objekte besitzt. Diese Objekte sind als Key-Value-Paare hinterlegt, die zu dem Owner gehören. Wird der Owner gelöscht so sind auch seine abhängigen Objekte nicht mehr gültig und können gelöscht werden. Dadurch können proaktiv mehrere Objekte aus dem Cache entfernt werden.

LRUCache

Der LRUCache ist ein auf das Expiry hin optimierter Cache.

Expiry

Als Expiry wird der automatisierte Prozess des Verwerfens von Elementen bezeichnet, um den Cache innerhalb einer gewissen Größe (Anzahl an Elementen, belegter Speicher,...) zu halten.

Das Auslösen des Expirys hängt bei dem LRUCache von zweierlei Bedingungen ab:

  1. Anzahl der Elemente im Cache

  2. Gesamtgröße aller Elemente im Cache

Der LRUCache kann die Gesamtgröße dadurch ermitteln, dass zu jedem Objekt das in den Cache gelegt wird eine Größe mitgegeben wird, die eine Annäherung an die Größe des Objekts ist.

Für den Vorgang des Expirys wird ein eigener LRU-Algorithmus [68] genutzt. Dieser ermöglicht das Expiry durch eine spezielle Verwaltung der Owner und Key/Value-Paare, auf das Owner-Konzept hin zu optimieren und den Fall des Expirys effizient zu lösen. Dabei ist es auch möglich zu definieren wie lange Elemente mindestens gehalten werden.

CompositeKeyCache

Der CompositeKeyCache ist ein auf Abfragen (gets) hin optimierter Cache. Als Zusatzmöglichkeiten bietet er ein Statistikmodul sowie die Möglichkeit Listener einzuhängen, um über Cache-bezogene Events informiert zu werden. Darüber hinaus enthält er ein JMX-Bean, welches eine alternative Möglichkeit bietet, diverse Informationen über den Cache zu erhalten und Basisoperationen darauf auszuführen.

Expiry

Das Expiry des CompositeKeyCaches basiert auf einem ExpiryStrategy-Inteface, das es ermöglicht verschiedene Expiry-Strategien modular einzuhängen. Dadurch ergibt sich die Möglichkeit diese auch bei Bedarf zu ändern. Standardmäßig wird ein LRU-Algorithmus[68], ähnlich dem des LRUCaches verwendet.

Statistics

Der CompositeKeyCache ermöglicht es Statistiken über die Cacheaktivitäten zu sammeln. Diese umfassen die Anzahl an:

hits

Erfolgreich beantworteten Anfragen ein Objekt aus dem Cache zu erhalten (Anfragen bei denen ein passendes Element gefunden werden konnte).

misses

Anfragen ein Objekt aus dem Cache zu erhalten, die nicht erfolgreich beantwortet wurden (Anfragen bei denen kein passendes Element gefunden werden konnte).

gets

Anfragen ein Objekt aus dem Cache zu erhalten.

puts

Operationen bei denen Elemente in den Cache gelegt wurden.

removals

Manuell entfernte Objekte aus dem Cache. Hat nichts mit Expiry oder Evictions zu tun.

evictions

Automatisch entfernte Objekte aus dem Cache, auf Grund des Expirys (gezwungenes Entfernen um in den Cachegrenzen zu bleiben). Diese werden separat von Removals gezählt.

Diese Option ist standardmäßig deaktiviert und kann über den Konstruktor

new CompositeKeyCache(…, true /* Enables statistics */);

oder über die explizite Methode

setCacheStatisticsEnabled(true);

oder über das JMX-Bean aktiviert werden.

Warnung

Das Sammeln von Statistiken kann Performanceeinbußen mit sich ziehen.

Ist die Sammlung von Statistiken aktiviert, so kann man diese programmatisch über die Methode

getCacheStatistics()

abrufen. Oder über das JMX-Bean eingesehen werden.

Events und Listener

Es gibt mehre definierte Events die beim Caching auftreten können, diese umfassen:

CREATED

Ein Cacheeintrag wurde erzeugt.

UPDATED

Ein Cacheeintrag wurde aktualisiert.

REMOVED

Ein Cacheeintrag wurde entfernt.

EXPIRED

Ein Cacheeintrag wurde auf Grund des Expirys entfernt.

CLEARED

Alle Cacheeinträge wurden gelöscht.

Für jedes dieser Events gibt es einen zugehörigen CacheEntryListener, den man mit

new CompositeKeyCache(…, …, true /* Enables listeners */);

am Cache registrieren kann. Sobald eines der genannten Events eintritt, wird jeder Listener der für dieses Event registriert wurde informiert.

Listener sind standardmäßig deaktiviert und können über den Konstruktor

setCacheListenersEnabled(true);

und über die explizite Methode

registerCacheEntryListener(cacheEntryListener);

oder über das standartmäßig aktivie JMX-Bean aktiviert werden.

Warnung

Listener können Performanceeinbußen mit sich ziehen.

Konfiguration

Das Setzen und Konfigurieren des Caches erfolgt über die Datei »Jadice.properties«, wie in „Allgemeine Jadice-Konfiguration“ erläutert. Für gewöhnlich sind hier jedoch keine Anpassungen notwendig.

Warnung

Änderungen an diesen Einstellungen können das Laufzeitverhalten erheblich beeinflussen und zu unerwünschten Performance-Einbüßen führen. Anpassungen sollten nur aus konkreten Anlass erfolgen und vor einer Produktivnahme validiert werden.

Im Folgenden sind die möglichen Einstellungen beschrieben. Alle Einstellungen sind möglich und anwendbar unabhängig von dem gewähltem Standard-Cache:

type

Verwendeter Cache

maxNumberOfCacheEntries

Maximalzahl an Cacheeinträgen

  • Mögliche Werte: Integer

  • Default: 30000

  • Beispiel: Konfiguration der maximalen Anzahl an Objekten auf 30000

    jadice.viewer.cache.maxNumberOfCacheEntries=30000

    Die Größe des Caches kann unter anderem über die maximale Anzahl an Elementen, die enthalten sein dürfen, begrenzt werden. Wird diese Grenze überschritten, werden so lange Elemente aus dem Cache entfernt, bis er sich wieder unterhalb der gegebenen Obergrenze befindet.

sizeHighwaterMark

Maximalgröße des Caches in Bytes (HighwaterMark)

  • Mögliche Werte: Integer (in Bytes)

  • Default: 2097152

  • Beispiel: Konfiguration von maximal 512MB (512*1024*1024=536870912 Byte) Cache-Speicher

    jadice.viewer.cache.sizeHighwaterMark=536870912

    Neben der maximalen Anzahl von Elementen kann die Größe des Caches auch (zusätzlich oder ausschließlich) über seinen maximalen Speicherverbrauch definiert werden. Da die Größe in Bytes eine angenäherte Größe ist, kann man hier keine Exaktheit erwarten. Wird sie überschritten, werden so lange Elemente aus dem Cache entfernt, bis man wieder unterhalb dieser Grenze ist. Es ist auch möglich, eine dynamische Grenze für den Speicherverbrauch zu setzen, siehe sizeHighwaterMarkPercent.

sizeHighwaterMarkPercent

Maximalgröße des Cache in Bytes in Abhängigkeit des maximalen Heapspaces

  • Mögliche Werte: Integer (in Prozent)

  • Default: 10

  • Beispiel: Konfiguration von maximal 25% des maximalen Heapspaces als Cache-Speicher

    jadice.viewer.cache.sizeHighwaterMarkPercent=25]]

    Ist keine sizeHighwaterMark gesetzt, so wird die Maximalgröße des Cache-Speichers anteilig zur Maximalgröße des Heapspaces ermittelt. Der in sizeHighwaterMarkPercent angegebene Wert gibt folglich an, wie viel Prozent des Heapspace dem Cache zustehen sollen. Ist dieser Wert fehlerhaft oder nicht angegeben, wird ein Wert von 10% angenommen.

minimumExpiryAge

Minimale Dauer, wie lange ein Eintrag gehalten werden soll

  • Mögliche Werte: Integer (in Millisekunden). Bei 0 wird dieser Faktor ignoriert

  • Default: 0

  • Beispiel: Konfiguration des Mindestalters auf 1 Sekunde (1000 Millisekunden)

    jadice.viewer.cache.minimumExpiryAge=1000

    Dieser Wert legt fest, wie lange Elemente mindestens im Cache verweilen, bevor sie beim Aufräumen entfernt werden.

maximumExpiryObjectCountRatio

Anteil an Elementen, die beim Aufräumen mindestens verworfen werden sollen

  • Mögliche Werte: Float (0.0 bis 1.0). Bei 0 wird dieser Faktor ignoriert

  • Beispiel: Konfiguration des Anteils an der Gesamtelementzahl von Elementen, der mindestens entfernt werden soll auf 0.1

    jadice.viewer.cache.maximumExpiryObjectCountRatio=0.1f

    Dieser Wert gibt an, wie viele der aktuellen Elemente bei jedem Aufräumvorgang zwingend entfernt werden sollen, um Platz für neue Elemente zu schaffen.



[68] Least Recently Used – Zuerst werden die Elemente verworfen, welche am wenigsten benutzt wurden.

[jadice document platform Version 5.5.12.1: Dokumentation für Entwickler. Veröffentlicht: 2021-08-17]