Tipps zur Leistungsanpassung für AEM 5.x

Problem

Die Leistung meiner CQ5-Instanz ist schlecht.

Ursache

Leistungsprobleme in CQ5 können aufgrund von vielen Dingen in Kombination eintreten. Am häufigsten ist die Ursache im Anwendungscode zu finden. Sie können jedoch innerhalb der CQ5-Konfiguration mehrere Maßnahmen ergreifen, um die Leistung zu verbessern.

Lösung

Um die Gesamtleistung der CQ-Instanz zu verbessern, empfiehlt Adobe, Folgendes zu tun (auf Autor- und Veröffentlichungsinstanzen).

 

1. Installieren Sie die empfohlenen Hotfixes

Dies gilt für AEM 5.6.1. Bitte lesen Sie sorgfältig https://helpx.adobe.com/de/experience-manager/kb/cq561-available-hotfixes.html und installieren Sie die empfohlenen Hotfixes für Ihre Module, insbesondere das Modul, das sich auf die Leistung bezieht.

 

2. Erhöhung von „bundleCacheSize“ CRX

Erhöhen Sie den Parameter bundleCacheSize von CRX TarPersistenceManager, indem Sie Folgendes tun:

Bearbeiten Sie jedes der PersistenceManager-Elemente in Ihrer repository.xml und all Ihre workspace.xml-Dateien, indem Sie den folgenden Parameter erhöhen innerhalb der <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager" /> Element:
Beispiel:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="bundleCacheSize" value="256" /> </PersistenceManager>

Standardmäßig ist dieser Cache auf 8 MB eingestellt. Erhöhen Sie den Wert auf mindestens 256 MB oder 512 MB, je nachdem, wie viel Speicher Sie der JVM zuweisen können. Wenn Sie eine JVM mit dem Xmx-Parameter auf 10 GB eingestellt haben, dann setzen Sie die bundleCacheSize auf 1024 MB. Wenn Sie eine 32-Bit-JVM bei Windows verwenden, ist Ihr Xmx-Parameter wahrscheinlich kleiner als 1500 MB. Ein angemessener Wert für die „bundleCacheSize“ ist daher 128 MB. Adobe empfiehlt ein Upgrade auf eine 64 Bit-JVM, um dem JVM-Heap mehr Speicherplatz zuzuweisen.

3. Verwenden Sie das „FineGrainedISMLocking“ (CRX 1.4.x only)

Um es zu konfigurieren, fügen Sie folgende ISMLocking-Klasse zu workspace.xml und repository.xml, direkt nach dem SearchIndex-Block:
hinzu

<Workspace ...> ... </SearchIndex> <ISMLocking class="org.apache.jackrabbit.core.state.FineGrainedISMLocking"/> ... </Workspace>

4. Deaktivieren Sie die „CQ5 AssetSynchronizationService“ (nur CQ 5.3)

Der AssetSynchronizationService synchronisiert Elemente aus eingehängten Repositorys (z. B. LiveLink, Documentum). Wenn diese Option aktiviert ist, kann es sein, dass dieser Dienst regelmäßig viele Objekte zuweist, die der Garbage Collection zum Opfer fallen. Daher hat sie Auswirkungen auf die Leistung der JVM. Wenn Sie keine eingehängten Repositorys verwenden, können Sie diesen Dienst deaktivieren.

Nach Konfiguration kann der Synchronisierungszeitraum auf eine höhere Anzahl von Sekunden (standardmäßig 300) gesetzt werden, wodurch dies nicht mehr ausgeführt wird.

Das angehängte Paket setzt die Synchronisierungsperiode auf ein Jahr und deaktiviert den Dienst.

5. Festlegen des resultFetchSize-Parameters des CRX-Suchindexes

Wenn der Ergebnissatz einer JCR-Anfrage sehr umfangreich ist, brauchen das Laden des vollständigen Satzes und das Überprüfen der ACLs hohe Leistung. Um dies zu beheben, grenzen Sie die Abrufgröße auf 50 ein, beispielsweise über das SearchIndex-Element in der workspace.xml-Datei:

<param name="resultFetchSize" value="50"/> Zum Beispiel:

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> </SearchIndex>

6. Setzen Sie den CRX Search cacheSize-Parameter fest

Die gesuchte „cacheSize“ kann auch im SearchIndex-Element in workspace.xml gesetzt werden. Setzen Sie diesen Parameter auf 100000:

<param name="cacheSize" value="100000" />

Beispiel:

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> <param name="cacheSize" value="100000" /> </SearchIndex>

 

Dieser Parameter ist hier dokumentiert.

7. Deaktivieren Sie das „CRX-Clustering“ (CRX 1.4, 2.0, 2.1)

Wenn ein System mit hoher Schreiblast ausgeführt wird (z. B. mit massiven Importen von DAM-Assets), können manchmal sogar relativ geringe Leistungsgewinne beim Schreiben helfen, den erforderlichen Leistungsbenchmark zu erreichen. In diesem Fall sollten Sie das Clustering-Journal in Ihrer Bereitstellung deaktivieren.

Standardmäßig ist CRX für die Ausführung im Cluster-Modus eingerichtet. Wenn jedoch nur eine Instanz im Cluster vorhanden ist, erhöht sich der „I/O-Overhead“. Deaktivieren Sie das Clustering, um Schreibleistung zu erhalten.

Löschen Sie in der Datei repository.xml den Abschnitt <Cluster ...>...</Cluster>.
Verwenden Sie anschließend das Beispielskript, um die Repository-Dateien vom Clustermodus auf den Einzelmodus zu verschieben.

Bevor Sie dieses Verfahren durchführen, wenden Sie sich an Ihren Daycare oder Ihren Kundenbetreuer, um diese Option zu besprechen. Die meisten Bereitstellungen von Benutzern werden mit den standardmäßigen Konfigurationen ausgeführt, die in Journalen beschrieben sind. Es empfiehlt sich, dieses Skript auf einer Testinstanz zu testen und es auf einem Produktionssystem auszuführen.

8. Aktualisieren des Content Finders und automatisches Laden deaktivieren (nur Autoreninstanz)

Weitere Informationen finden Sie in diesem Artikel [2]

9. DAM Sub Asset Generation deaktivieren

Weitere Informationen finden Sie in diesem Artikel [3]

10. Begrenzung der maximalen Journalgröße in CRX

Wenn die CRX-Journaldateien unter „Freigeben/Journal“ zu groß sind, kann die Anwendung etwas verlangsamt werden. Lesen Sie diesen Artikel [4] für die Begrenzung der Journalgröße und der maximalen Anzahl von Dateien.

11. DAM-Workflows beim Publizieren deaktivieren (nur CQ 5.3 Publish instance)

Weitere Informationen finden Sie in diesem Artikel [5]

12. Link Checker deaktivieren

Ein Performance-Gewinn kann durch Deaktivieren des Link Checker (insbesondere mit AEM 5.6.1) erzielt werden. Tun Sie das nur, wenn Sie sich dafür entscheiden, dass Sie das in Ihrer Umgebung nicht brauchen.

Der Link-Checker überprüft, ob Ressourcen-URLs auf Ihren Seitenadressen erreichbar sind. Dies geschieht über eine HTTP HEAD-Anfrage.

Wenn ein Link im Autor als ungültig markiert ist, zeigt der Link-Checker ein unterbrochenes Kettensymbol an. Wenn ein Link beim Veröffentlichen als ungültig markiert wird, wird das umgebende <a href="...">-Tag entfernt.

Einige Clients deaktivieren die Tags in ihren Veröffentlichungsinstanzen, um die Leistung zu verbessern. Obwohl dies zu Leistungssteigerungen führt, beeinträchtigen defekte Links die SEO Ihrer Site. Berücksichtigen Sie die Auswirkungen sorgfältig, bevor Sie sich dazu entscheiden, sie zu deaktivieren.

Anweisungen zum Deaktivieren dieser Funktion finden Sie in diesem Artikel [6].

13. Cache Tar PM Index

Bis CRX 2.1

Die Verwendung eines Cron-Auftrags, um die index*.tar-Datei von Zeit zu Zeit zu lesen, kann zur Verbesserung der Leistung beitragen, da der tar-Index im Hardware-E / A-Cache zwischengespeichert wird. Unter UNIX können Sie den index*.tar mit dem Befehl „cat index*.tar > /dev/null“ laden. Dies einmal pro Stunde zu tun, sollte dazu beitragen, die Leistung des Tar Persistence Manager während der Ausführung der TarFile.readFully ()-Methode zu verbessern.

Von CRX 2.2 + Hotfixpack 2.2.0.26 und höher

Überprüfen Sie die globale Größe der index_*.tar-Dateien im crx.default-Arbeitsbereich. Erhöhen Sie die maximale Größe des Heapspeichers um diese Größe, und setzen Sie den Parameter „indexInMemory“ für den Abschnitt „TarPersistenceManager“ der workspace.xml auf true.

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="indexInMemory" value="true" />
</PersistenceManager>

Der für einen JCR-Knoten erforderliche Heap-Speicherplatz beträgt 128 Byte. Wenn die größte index_*.tar-Datei eines Arbeitsbereichs 1 GB beträgt, bedeutet dies, dass sich in diesem Arbeitsbereich etwa 16 Millionen Knoten befinden, da jeder Knoten 64 Byte Speicherplatz benötigt. Die Verwendung der In-Memory-Index-Option benötigt ca. 2 GB Heap-Speicherplatz (doppelte Dateigröße zur Berechnung des benötigten Heap-Speicherplatzes, da es beim Index-Merge zwei Versionen pro Indexdatei geben kann).

14. LDAP-Cache-Ablauf

Um die Leistung zu verbessern und die Latenz während des Authentifizierungsprozesses zu reduzieren, ist es gut, den LDAP-Cache-Ablauf zu erhöhen. Sie können in Ihrer LDAP-Konfiguration „cache.expiration“ auf 86400 (ein Tag) setzen.

15. Optimieren Sie den Lucene-Index, um Speicherplatz und Effizienz zu gewinnen.

Weitere Informationen finden Sie in diesem Artikel [7]

Quellennachweis

[1] http://wiki.apache.org/jackrabbit/Search
[2] Wie ändert man das ContentFinder-Refreshintervall
[3] Wie entfernt man Subasset-Generierung aus DAM Workflow
[4] Journal verbraucht auch viel Speicherplatz
[5] Wie man DAM-Workflows bei publish ausschaltet
[6] Linkchecker ausschalten
[7] Optimieren Sie den Lucene-Index, um Speicherplatz und Effizienz zu gewinnen

 

Gilt für

CQ 5.x, CRX 2.x