Wenn Sie eXtremeMemory konfigurieren, können Sie Objekte im nativen Speicher anstelle des Java-Heapspeichers speichern. Die Konfiguration von eXtremeMemory aktiviert eXtremeIO, einen neuen Transportmechanismus. Durch die Auslagerung von Objekten aus dem Java-Heapspeicher können Sie Garbage-Collection-Pausen vermeiden und damit eine konstantere Leistung und vorhersehbare Antwortzeiten erzielen.
Die JVM stützt sich bei der Erfassung, Verkleinerung und Vergrößerung des Prozessspeichers auf Nutzungsheuristik. Der Garbage-Collector führt diese Operationen aus. Durch die Garbage-Collection entstehen jedoch Kosten. Die Kosten für die Garbage-Collection nehmen mit der Größe des Heapspeichers und der Anzahl der Objekte im Datengrid zu. Die JVM stellt verschiedene heuristische Verfahren für verschiedene Anwendungsfälle und Ziele bereit: optimaler Durchsatz, optimale Pausenzeiten, auf dem Objektalter basierende Garbage-Collection, gleichmäßige Verteilung und Garbage-Collection in Echtzeit. Kein heuristisches Verfahren ist perfekt. Ein einziges heuristisches Verfahren kann nicht für alle Konfigurationen geeignet sein.
WebSphere eXtreme Scale verwendet Datencaching mit verteilten Maps, die Einträge mit einem bekannten Lebenszyklus haben. Dieser Lebenszyklus enthält die folgenden Operationen: GET, INSERT, DELETE und UPDATE. Durch die Verwendung dieser bekannten Map-Lebenszyklen können eXtremeMemory und eXtremeIO den Speicher effizienter nutzen als die JVM-Nutzungsheuristik.
Die folgende Abbildung veranschaulicht, wie mit eXtremeMemory konsistentere relative Antwortzeiten in der Umgebung erzielt werden. Im Bereich der hohen Perzentile sind die relativen Antwortzeiten bei Anforderungen, die eXtremeMemory verwenden, wesentlich kürzer. In der Abbbildung sind die 95-100 Perzentile dargestellt.
.