Leistung mit Bytefeldgruppen-Maps verbessern

Sie können Werte in Ihren Maps in einer Bytefeldgruppe anstatt im POJO-Format speichern, was den Speicherbedarf eines großen Objektgraphen reduziert.

Vorteile

Die Speicherbelegung steigt mit der Anzahl der Objekte im Objektgraphen. Indem Sie einen komplexen Objektgraphen zu einer Bytefeldgruppe reduzieren, wird nur noch ein einziges Objekt an Stelle mehrerer Objekte im Heapspeicher verwaltet. Durch die Reduktion der Objektanzahl im Heapspeicher muss die Java-Laufzeitumgebung während der Garbage-Collection weniger Objekte suchen.

Der von WebSphere eXtreme Scale verwendete Standardkopiermechanismus ist die Serialisierung, die kostenintensiv ist. Wenn Sie beispielsweise den Standardkopiermodus COPY_ON_READ_AND_COMMIT verwenden, wird jeweils beim Lesen und beim Abrufen eine Kopie erstellt. Anstatt eine Kopie beim Lesen zu erstellen, wird der Wert mit Bytefeldgruppen aus den Bytes wiederhergestellt, und anstatt eine Kopie bei der Festschreibung zu erstellen, wird der Wert in Bytes serialisiert. Die Verwendung von Bytefeldgruppen liefert dieselbe Datenkonsistenz wie die Standardeinstellung mit Reduktion der Speicherbelegung.

Wenn Sie Bytefeldgruppen verwenden, ist der Einsatz eines optimierten Serialisierungsmechanismus von entscheidender Bedeutung, um eine Reduktion der Speicherbelegung zu erzielen. Weitere Informationen finden Sie im Abschnitt Serialisierungsleistung optimieren.

Maps für Bytefeldgruppen konfigurieren

Sie können Maps für Bytefeldgruppen über die ObjectGrid-XML-Datei aktivieren, indem Sie das von einer Map verwendete Attribut "CopyMode", wie im folgenden Beispiel gezeigt, auf COPY_TO_BYTES setzen:

<backingMap name="byteMap" copyMode="COPY_TO_BYTES" />

Hinweise

Sie müssen prüfen, ob sich die Verwendung von Maps für Bytefeldgruppen in einem bestimmten Szenario eignet oder nicht. Die Speicherbelegung reduziert sich zwar bei der Verwendung von Bytefeldgruppen, aber die Prozessorauslastung kann zunehmen.

In der folgenden Liste sind verschiedene Faktoren beschrieben, die Sie berücksichtigen sollten, bevor Sie sich für die Verwendung von Maps für Bytefeldgruppen entscheiden.

Objekttyp

Für einige Objekttypen ist bei der Verwendung von Maps für Bytefeldgruppen unter Umständen keine Reduktion der Speicherbelegung möglich. Deshalb gibt es auch verschiedene Objekttypen, für die Sie keine Maps für Bytefeldgruppen verwenden sollten. Wenn Sie einen der primitiven Java-Wrapper als Wert verwenden oder ein POJO, das keine Referenzen auf andere Objekte enthält (sondern nur primitive Felder speichert), ist die Anzahl der Java-Objekte bereits so niedrig wie möglich, nämlich eins. Da die Speicherbelegung für das Objekt bereits optimiert ist, wird die Verwendung einer Map für Bytefeldgruppen für diese Objekttypen nicht empfohlen. Maps für Bytefeldgruppen eignen sich besser für Objekttypen, die andere Objekte oder Objektsammlungen enthalten, in denen die Gesamtanzahl der POJO-Objekte größer als eins ist.

Wenn Sie beispielsweise ein Objekt "Customer" haben, das eine Geschäftsadresse (Business Address) und eine Privatadresse (Home Address) sowie eine Sammlung von Aufträgen (Order) hat, können die Anzahl der Objekte im Heapspeicher und die Anzahl der von diesen Objekten belegten Bytes durch die Verwendung von Maps für Bytefeldgruppen reduziert werden.

Lokaler Zugriff

Werden andere Kopiermodi verwendet, können Anwendungen bei der Erstellung von Kopien optimiert werden, wenn Objekte mit dem Standard-ObjectTransformer klonbar sind oder wenn ein angepasster ObjectTransformer mit einer optimierten Methode "copyValue" bereitgestellt wird. Verglichen mit den anderen Kopiermodi, fallen für das Kopieren bei Lese-, Schreib- und Festschreibungsoperationen zusätzliche Kosten an, wenn lokal auf Objekte zugegriffen wird. Wenn Sie beispielsweise einen nahen Cache in einer verteilten Topologie haben oder direkt auf eine lokale oder Server-ObjectGrid-Instanz zugreifen, nehmen die Zugriffs- und Festschreibungszeiten bei der Verwendung von Maps für Bytefeldgruppen aufgrund der Serialisierungskosten zu. Ein ähnlicher Aufwand ist in einer verteilten Topologie zu verzeichnen, wenn Sie DataGrid-Agenten verwenden oder bei der Verwendung des ObjectGridEventGroup.ShardEvents-Plug-ins auf die primäre Partition des Servers zugreifen.

Plug-in-Interaktionen

Wenn Sie Maps für Bytefeldgruppen verwenden, werden Objekte bei der Kommunikation zwischen einem Client und einem Server nicht dekomprimiert, es sei denn, der Server benötigt das POJO-Format. Plug-ins, die mit dem Map-Wert interagieren, verzeichnen Leistungseinbußen, weil der Wert dekomprimiert werden muss.

Jedes Plug-in, das "LogElement.getCacheEntry" oder "LogElement.getCurrentValue" verwendet, weist diesen erhöhten Aufwand auf. Wenn Sie den Schlüssel abrufen möchten, können Sie die Methode "LogElement.getKey" verwenden, die den zusätzlichen Aufwand vermeidet, den die Methode "LogElement.getCacheEntry().getKey" mit sich bringt. In den folgenden Absätzen wird die Wirkung von Bytefeldgruppen auf Plug-ins erläutert.

Indizes und Abfragen

Wenn Objekte im POJO-Format gespeichert werden, sind die Kosten für die Indexierung und Abfragen minimal, weil das Objekt nicht dekomprimiert werden muss. Wenn Sie eine Map für Bytefeldgruppen verwenden, entstehen zusätzliche Kosten für die Dekomprimierung des Objekts. Wenn Ihre Anwendung Indizes oder Abfragen verwendet, wird im Allgemeinen von der Verwendung von Maps für Bytefeldgruppen abgeraten, sofern Sie die Abfragen nicht ausschließlich für Schlüsselattribute durchführen.

Optimistisches Sperren

Wenn Sie die optimistische Sperrstrategie verwenden, entstehen zusätzliche Kosten bei Operationen zum Aktualisieren oder Ungültigmachen von Einträgen. Dies ist darauf zurückzuführen, dass der Wert im Server dekomprimiert werden muss, um den Versionswert für die optimistische Kollisionsprüfung abzurufen. Wenn Sie optimistisches Sperren nur verwenden, um Abrufoperationen (fetch) zu gewährleisten und keine optimistische Kollisionsprüfung benötigen, können Sie "com.ibm.websphere.objectgrid.plugins.builtins.NoVersioningOptimisticCallback" verwenden, um die Versionsprüfung zu inaktivieren.

Loader

Auch bei einem Loader (Ladeprogramm) fallen in der eXtreme-Scale-Laufzeitumgebung Kosten für die Dekomprimierung und erneute Serialisierung des Werts an, wenn er vom Loader verwendet wird. Sie können für Loader trotzdem Maps für Bytefeldgruppen verwenden, müssen aber die Kosten berücksichtigen, die durch das Ändern des Werts in einem solchen Szenario anfallen. Sie können das Feature für Bytefeldgruppen beispielsweise im Kontext eines Caches verwenden, in dem hauptsächlich Leseoperationen durchgeführt werden. In diesem Fall überwiegen die Vorteile, weniger Objekte im Heapspeicher und weniger Speicherbelegung zu haben, die Kosten, die durch die Verwendung von Bytefeldgruppen bei Einfüge- und Aktualisierungsoperationen anfallen.

ObjectGridEventListener

Wenn Sie die Methode "transactionEnd" im ObjectGridEventListener-Plug-in verwenden, entstehen zusätzliche Kosten auf der Serverseite für Fernanforderungen beim Zugriff auf den Cacheeintrag eines LogElement-Objekts oder auf den aktuellen Wert. Wenn die Implementierung der Methode nicht auf diese Felder zugreift, entstehen keine zusätzlichen Kosten.