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. LRUCache ist als Standard Cache voreingestellt.
Verwaltet werden die Caches über den CacheManager. Dort lässt sich der
Standardcache setzen und erfragen.
In den jadice utils gibt es zwei Caches: Den LRUCache und den
CompositeKeyCache.
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.
Der LRUCache ist ein auf das Expiry hin optimierter Cache.
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:
-
Anzahl der Elemente im Cache
-
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.
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.
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.
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.
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.
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
-
Mögliche Werte:
CompositeKeyCache,LRUCache -
Default:
CompositeKeyCache -
Beispiel: Verwendung des
CompositeKeyCachejadice.viewer.cache.type=CompositeKeyCache
Setzt den Cache, der verwendet werden soll.
-
-
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
sizeHighwaterMarkgesetzt, so wird die Maximalgröße des Cache-Speichers anteilig zur Maximalgröße des Heapspaces ermittelt. Der insizeHighwaterMarkPercentangegebene 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.
