Die Anwendungsprogrammierschnittstelle (API, Application Programming Interface) für dynamischen Cache steht Java-EE-Anwendungen zur Verfügung, die in WebSphere Application Server implementiert sind. Der dynamische Cache kann genutzt werden, um Geschäftsdaten und generierte HTML zwischenzuspeichern oder um die zwischengespeicherten Daten in der Zelle über den Datenreplikationsservice (DRS) zu synchronisieren.
Alle dynamischen Cacheinstanzen, die mit dem dynamischen Cache-Provider von WebSphere eXtreme Scale erstellt werden, sind standardmäßig hoch verfügbar. Die Stufe und die Speicherkosten der hohen Verfügbarkeit sind von der verwendeten Topologie abhängig.
Wenn Sie die integrierte Topologie verwenden, ist die Cachegröße auf den freien Speicher in einem einzelnen Serverprozess beschränkt, und in jedem Serverprozess wird eine vollständige Kopie des Caches gespeichert. Solange auch nur ein einziger Serverprozess aktiv ist, bleibt auch der Cache aktiv. Die Cachedaten gehen nur dann verloren, wenn alle Server, die auf den Cache zugreifen, beendet werden.
Beim Caching mit der integrierten partitionierten Topologie ist die Cachegröße auf den summierten freien Speicher aller Serverprozesse beschränkt. Standardmäßig verwendet der dynamische Cache-Provider von eXtreme Scale ein Replikat für jedes primäre Shard, d. h., jedes einzelne zwischengespeicherte Datenelement wird zweimal gespeichert.
Verwenden Sie die folgende Formel A, um die Kapazität eines integrierten partitionierten Caches zu bestimmen:
Formel A
F * C / (1 + R) = M
Für ein Datengrid von WebSphere Application Server Network Deployment mit 256 MB verfügbarem Speicher in jedem Prozess und 4 Serverprozessen insgesamt können in einer Cacheinstanz über alle diese Server verteilt 512 Megabyte Daten gespeichert werden. In diesem Modus kann der Cache einen Serverabsturz ohne Datenverlust "überleben". Es könnten sogar nacheinander zwei Server beendet werden, ohne dass irgendwelche Daten verloren gehen. Für das vorherige Beispiel lautet die Formel deshalb wie folgt:
256 MB * 4 Container/ (1 primäres Shard + 1 Replikat) = 512 MB
Caches, die die ferne Topologie verwenden, haben ähnliche Größenmerkmale wie Caches, die die integrierte partitionierte Topologie verwenden, sind jedoch auf den summierten verfügbaren Speicher aller Containerprozesse von eXtreme Scale beschränkt.
In fernen Topologien kann die Anzahl der Replikate erhöht werden, um eine höhere Stufe der Verfügbarkeit zu erreichen, wodurch sich jedoch der Speicheraufwand erhöht. In den meisten dynamischen Cacheanwendungen ist dies in der Regel nicht erforderlich, aber Sie können die Datei dynacache-remote-deployment.xml bearbeiten, um die Anzahl der Replikate zu erhöhen.
Verwenden Sie die folgenden Formeln (B und C), um zu berechnen, welche Auswirkungen das Hinzufügen weiterer Replikate auf die hohe Verfügbarkeit des Caches hat.
Formel B
N = Minimum(T -1, R)
Formel C
Obere Grenze(T/ (1+N)) = m
Informationen zur Leistungsoptimierung mit dem dynamischen Cache-Provider finden Sie im Abschnitt Dynamischen Cache-Provider optimieren.
Bevor eine Anwendung, die den dynamischen Cache-Provider von WebSphere eXtreme Scale verwendet, implementiert werden kann, müssen die allgemeinen Principals, die im vorherigen Abschnitt beschrieben wurden, mit den Umgebungsdaten für die Produktionssysteme kombiniert werden. Der erste zu ermittelnde Wert ist die Gesamtanzahl der Containerprozesse und der verfügbare Hauptspeicher jedes einzelnen Prozesses zum Speichern der Cachedaten. Wenn Sie die integrierte Topologie verwenden, befinden sich die Cachecontainer in den Prozessen von WebSphere Application Server. d. h., es gibt einen Container pro Server, der den Cache verwendet. Die Bestimmung der Speicherkosten der Anwendung ohne aktiviertes Caching und ohne WebSphere Application Server ist die beste Methode zu ermitteln, wie viel Speicher im Prozess verfügbar ist. Zur Ermittlung dieses Werts bietet sich die Analyse der Daten einer ausführlichen Garbage-Collection an. Wenn Sie die ferne Topologie verwenden, können diese Informationen anhand der Ausgabe der ausführlichen Garbage-Collection für einen neu gestarteten eigenständigen Container ermittelt werden, der noch nicht mit Cachedaten gefüllt wurde. Ein letzter Aspekt, der bei der Ermittlung des für Cachedaten verfügbaren Speichers pro Prozess berücksichtigt werden muss, ist die Reservierung einer gewissen Menge des Heapspeichers für die Garbage-Collection. Die Summe aus Containerkosten (Umgebung mit WebSphere Application Server oder eigenständige Umgebung) und reservierter Größe für den Cache sollte nicht mehr als 70 % der Gesamtgröße des Heapspeichers betragen.
Nachdem Sie diese Informationen zusammengestellt haben, können Sie die Werte in die zuvor beschriebene Formel A eintragen, um die maximale Größe für den partitionierten Cache zu bestimmen. Sobald die maximale Größe bekannt ist, müssen Sie im nächsten Schritt die Gesamtanzahl der Cacheeinträge bestimmen, die unterstützt werden können. Hierfür muss zunächst die durchschnittliche Größe pro Cacheeintrag bestimmt werden. Eine einfache Methode zur Bestimmung dieses Werts ist, 10 % auf die Größe des Kundenobjekts aufzuschlagen. Ausführlichere Informationen zur Festlegung der Größe von Cacheeinträgen bei der Verwendung des dynamischen Caches finden Sie in der Veröffentlichung "Tuning guide for dynamic cache and data replication service".
Wenn die Komprimierung aktiviert ist, wirkt diese sich auf die Größe des Kundenobjekts aus, aber nicht auf die Kosten des Caching-Systems. Verwenden Sie die folgende Formel, um die Größe eines zwischengespeicherten Objekts zu bestimmen, wenn Sie mit Komprimierung arbeiten:
S = O * C + O * 0.10
Anschließend verwenden Sie diese Informationen, um die Gesamtanzahl der Cacheeinträge zu bestimmen, die unterstützt werden können. Verwenden Sie die folgende Formel D:
Formel D
T = S / A
Formel E
Cs = Ts / Np