Allgemeine Richtlinien zur Leistung finden Sie auf der Seite Leistungsrichtlinien.
Weitere Informationen zur Fehlerbehebung und zur Beseitigung von Leistungsproblemen finden Sie außerdem im Leistungsbaum.
Darüber hinaus können Sie einen Artikel in der Wissensdatenbank unter Tipps zur Leistungsoptimierung lesen.
Ein wichtiger Faktor ist die Zeit, die Ihre Website benötigt, um auf Anforderungen durch Besucher zu reagieren. Obwohl dieser Wert für jede Anforderung anders ist, kann ein durchschnittlicher Zielwert definiert werden. Sobald sich gezeigt hat, dass dieser Wert längerfristig erreichbar ist, kann er verwendet werden, um die Leistung der Website zu überwachen und auf potenzielle Probleme hinzuweisen.
Die von Ihnen angestrebten Antwortzeiten sind aufgrund der unterschiedlichen Zielgruppen in der Autoren- und der Veröffentlichungsumgebung wahrscheinlich unterschiedlich:
Diese Umgebung wird von Autoren zur Eingabe und Aktualisierung von Inhalten verwendet. Sie muss für eine kleine Anzahl von Benutzern geeignet sein, von denen jeder zahlreiche leistungsintensive Anforderungen beim Aktualisieren von Inhaltsseiten und einzelnen Elementen auf diesen Seiten erzeugt.
Diese Umgebung enthält Inhalte, die Sie Ihren Benutzern zugänglich machen. Hier ist die Anzahl der Anfragen sogar noch größer und die Geschwindigkeit ist ebenso wichtig, aber da die Art der Anfragen weniger dynamisch ist, können zusätzliche leistungssteigernde Mechanismen angewendet werden. wie das Zwischenspeichern des Inhalts oder den Lastenausgleich.
Eine Leistungsoptimierungsmethodik für AEM Projekte lässt sich in fünf sehr einfachen Regeln zusammenfassen, die zur Vermeidung von Leistungsproblemen des Beginns befolgt werden können:
Diese Regeln gelten weitgehend für Webprojekte im Allgemeinen und sind für Projektmanager und Systemadministratoren relevant, um sicherzustellen, dass ihre Projekte nicht vor Leistungsproblemen stehen, wenn die Startzeit eintritt.
Ca. 10 % der Projektarbeit sollten für die Leistungsoptimierung reserviert werden. Natürlich hängen die tatsächlichen Anforderungen an die Leistungsoptimierung von der Komplexität eines Projekts und der Erfahrung des Entwicklerteams ab. Auch wenn Ihr Projekt nicht die gesamte einkalkulierte Zeit beanspruchen sollte, ist es empfehlenswert, bei der Leistungsoptimierung die vorgeschlagene Zeit zu berücksichtigen.
Wenn möglich, sollte ein Projekt zunächst weich auf eine begrenzte Audience gestartet werden, um echte Erfahrungen zu sammeln und weitere Optimierungen durchzuführen, ohne den zusätzlichen Druck, der auf eine vollständige Ankündigung folgt.
Doch auch nach dem Launch muss die Projektoptimierung fortgesetzt werden. Der Lauch ist der Moment, in dem Ihr System einer „echten“ Belastung ausgesetzt wird. Deshalb sollten nach dem Launch zusätzliche Anpassungen eingeplant werden.
Da die Systembelastung variiert und sich die Leistungsprofile Ihres Systems im Laufe der Zeit verändern, sollte alle sechs bis zwölf Monate eine Leistungsanpassung oder eine Systemüberprüfung vorgenommen werden.
Wenn Sie nach dem Launch einer Website feststellen, dass Leistungsprobleme auftreten, gibt es nur einen Grund dafür: In Ihren Belastungs- und Leistungstests wurde die Realität nicht gut genug simuliert.
Die Simulation der Realität ist schwierig, und wie viel Mühe Sie vernünftigerweise investieren wollen, um "real" zu werden, hängt von der Natur Ihres Projekts ab. „Real“ bedeutet nicht nur „realer Code“ und „realer Traffic“, sondern auch „realer Inhalt“, insbesondere was die Inhaltsgröße und Struktur anbelangt. Ihre Vorlagen können sich nämlich je nach Größe und Struktur des Repositorys völlig anders verhalten.
Die Bedeutung einer ordnungsgemäßen Festlegung von Leistungszielen ist nicht zu unterschätzen. Oft ist es sehr schwierig, diese Ziele nachträglich zu ändern, sobald Menschen sich auf bestimmte Leistungsziele konzentrieren, selbst wenn sie auf wilden Annahmen beruhen.
Das Festlegen guter, konkreter Leistungsziele ist eine der schwierigsten Aufgaben. Oft empfiehlt es sich, echte Protokolle und Benchmarks von einer vergleichbaren Website heranzuziehen (z. B. vom Vorgänger der neuen Website).
Es ist wichtig, immer jeweils einen Engpass nach dem anderen zu optimieren. Wenn Sie mehrere Maßnahmen gleichzeitig treffen, ohne die Auswirkungen der einzelnen Optimierungen zu überprüfen, wissen Sie nicht, welche Optimierungsmaßnahme tatsächlich erfolgreich war.
Im Zuge der Leistungsanpassung werden Werte immer wieder gemessen, analysiert, optimiert und validiert, bis der Zielwert erreicht ist. Um diesem Aspekt gebührend Rechnung zu tragen, implementieren Sie nach jeder Iteration einen agilen Validierungsprozess in der Optimierungsphase und nicht einen aufwändigeren Testprozess, der eine größere Gewichtung ermöglicht.
Der Entwickler, der die Optimierung durchführt, sollte rasch erkennen können, ob mit einer Optimierung der Zielwert erreicht wurde. Dies ist eine wertvolle Information, denn sobald der Zielwert erreicht ist, ist die Optimierung abgeschlossen.
Im Allgemeinen sollten nicht gecachte HTML-Anforderungen weniger als 100 ms benötigen. Konkret wird Folgendes empfohlen:
Bei den obigen Zahlen gelten die folgenden Bedingungen:
Häufige Ursachen für einen Leistungsabfall sind vor allem:
Anpassungen auf JVM- und Betriebssystemebene bedingen normalerweise keine großen Leistungssprünge und sollten deshalb ganz am Ende des Optimierungszyklus ausgeführt werden.
Die Struktur des Inhaltsrepositorys kann sich ebenfalls auf die Leistung auswirken. Die beste Leistung wird erzielt, wenn die Anzahl der untergeordneten Knoten in einem Inhaltsrepository 1.000 nicht übersteigt (allgemeine Regel).
Besonders wichtig in einem herkömmlichen Leistungsoptimierungsschritt sind:
request.log
Aufgrund des großen Datenvolumens beim Laden und Bearbeiten von digitalen Assets können Leistungsprobleme auftreten.
Die Leistung hängt dabei von zwei Faktoren ab:
Stellen Sie zur Leistungssteigerung die folgenden Überlegungen an:
Leistung (oder fehlende Leistung) ist das Erste, was Ihre Benutzer bemerken. Deshalb ist die Leistung wie bei jeder Anwendung mit einer Benutzeroberfläche von größter Bedeutung. Um die Leistung Ihrer AEM zu optimieren, müssen Sie verschiedene Attribute der Instanz und deren Verhalten überwachen.
Informationen zur Durchführung der Leistungsüberwachung finden Sie unter Überwachungsleistung.
Die Faktoren, die Leistungsprobleme verursachen, sind oft schwer zu erkennen, selbst wenn ihre Auswirkungen offenkundig sind.
Eine gute Basis ist die umfassende Kenntnis Ihres Systems bei Normalbetrieb. Wenn Sie nicht wissen, wie Ihre Umgebung im Normalbetrieb „aussieht“ und sich „verhält“, ist es schwierig, die Ursache eines Leistungsabfalls zu ermitteln. Deshalb sollten Sie sich Ihr System während des reibungslosen Betriebs genau ansehen und laufend Leistungsinformationen erfassen. Dies bietet Ihnen eine Vergleichsbasis, falls sich die Leistung verschlechtert.
Das folgende Diagramm zeigt den Pfad, den eine Anforderung für AEM Inhalt annehmen kann, und somit die Anzahl der verschiedenen Elemente, die die Leistung beeinflussen können.
Leistung ist auch ein Gleichgewicht zwischen Volumen und Kapazität:
Dies kann an unterschiedlichen Stellen des Web-Pfads veranschaulicht werden.
Es gibt einige Funktionsbereiche, die häufig für eine Leistungsminderung verantwortlich sind:
Gewisse Regeln sollten bei der Leistungsoptimierung beachtet werden:
Bedenken Sie, dass der zur Leistungsmessung verwendete Mechanismus häufig genau das beeinflusst, was Sie messen möchten. Sie sollten diese Aspekte stets berücksichtigen und dafür sorgen, dass ihre Auswirkungen möglichst gering gehalten werden. Insbesondere sollten Browser-Plug-ins deaktiviert werden.
Bestimmte Aspekte von AEM (bzw. des zugrunde liegenden Repositorys) können so konfiguriert werden, dass die Leistung optimiert wird. Im Folgenden werden Möglichkeiten und Vorschläge beschrieben. Überprüfen Sie zuerst, ob und wie Sie die beschriebene Funktionalität verwenden können, bevor Sie Änderungen vornehmen.
Weitere Informationen finden Sie im Artikel in der Wissensdatenbank.
Ab AEM 6.0 wird eine Oak-basierte Repository-Architektur verwendet.
Hier finden Sie die aktuellen Indizierungsinformationen:
Begrenzen Sie die Anzahl der parallel ausgeführten Workflow-Prozesse, um die Leistung zu verbessern. Standardmäßig entspricht die Anzahl der gleichzeitig von der Workflow-Engine verarbeiteten Workflows der Anzahl der für die Java VM verfügbaren Prozessoren. Wenn Workflow-Schritte große Mengen an Verarbeitungsressourcen erfordern (RAM oder CPU), kann die parallele Ausführung mehrerer dieser Workflows hohe Anforderungen an verfügbare Serverressourcen stellen.
Wenn beispielsweise Bilder (oder DAM-Assets im Allgemeinen) hochgeladen werden, importieren Workflows diese Bilder automatisch in DAM. Bilder besitzen häufig eine hohe Auslösung, wodurch oft hunderte von MB in Heap-Speichern zur Verarbeitung beansprucht werden. Die gleichzeitige Verarbeitung solcher Bilder bedeutet eine hohe Last für das Speicher-Subsystem und den Garbage Collector.
Die Workflow-Engine verwendet Apache Sling-Auftragswarteschlangen zur Handhabung und Planung der Verarbeitung der Arbeitselemente. Die folgenden Auftragswarteschlangendienste wurden standardmäßig aus der Konfigurationsdienstfactory des Apache Sling Job Queue für die Verarbeitung von Workflow-Aufträgen erstellt:
Konfigurieren Sie diese Dienste, um die maximale Anzahl der parallel ausgeführten Workflow-Prozesse zu beschränken.
Das Konfigurieren dieser Auftragswarteschlangen wirkt sich auf alle Workflows aus, es sei denn, Sie haben eine Auftragswarteschlange für ein bestimmtes Workflow-Modell erstellt (siehe Warteschlange für ein bestimmtes Workflow-Modell konfigurieren unten).
Wenn Sie die Dienste mit dem Knoten sling:OsgiConfig](/docs/experience-manager-65/deploying/configuring/configuring-osgi.html?lang=de#adding-a-new-configuration-to-the-repository) konfigurieren, müssen Sie die PID der vorhandenen Dienste suchen, z. B.: org.apache.sling.Ereignis.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. [ Sie können den PID mithilfe der Webkonsole ermitteln.
Sie müssen die Eigenschaft queue.maxparallel
konfigurieren.
Um diese Dienste mithilfe der Web-Konsole zu konfigurieren, suchen Sie die vorhandenen Konfigurationselemente unterhalb der Apache Sling Job Queue Configuration Service-Factory.
Sie müssen die Eigenschaft Maximum Parallel Jobs konfigurieren.
Erstellen Sie eine Auftragswarteschlange für ein bestimmtes Workflow-Modell, sodass Sie die Auftragsabwicklung für dieses Workflow-Modell konfigurieren können. Dadurch wird die Verarbeitung dieses Workflows durch Ihre Konfigurationen gesteuert, während die Verarbeitung anderer Workflows durch die Konfiguration der standardmäßigen Granite Workflow Queue gesteuert wird.
Wenn Workflow-Modelle ausgeführt werden, erstellen sie Sling-Aufträge für ein bestimmtes Thema. Standardmäßig entspricht das Thema den Themen, die für die allgemeine Granite Workflow Queue oder die Granite Workflow External Process Job Queue konfiguriert werden:
com/adobe/granite/workflow/job*
com/adobe/granite/workflow/external/job*
Zu den eigentlichen Auftragsthemen, die von Workflow-Modellen generiert werden, zählen modellspezifische Suffix. Beispielsweise generiert das Workflow-Modell DAM Update Asset Aufträge mit folgendem Thema:
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
Daher können Sie eine Auftragswarteschlange für das Thema erstellen, das dem Auftragsthema Ihres Workflow-Modells entspricht. Die Konfiguration der Leistungseigenschaften der Warteschlange wirkt sich nur auf das Workflow-Modell aus, das die Aufträge generiert, die dem Warteschlangenthema entsprechen.
Im folgenden Verfahren wird eine Auftragswarteschlange für einen Workflow erstellt, wobei als Beispiel der Arbeitsablauf DAM Update Asset verwendet wird.
Führen Sie das Workflow-Modell aus, für das Sie die Auftragswarteschlange erstellen möchten, sodass Themenstatistiken generiert werden. Fügen Sie beispielsweise Assets ein Bild hinzu, um den Arbeitsablauf DAM-Update-Asset auszuführen.
Öffnen Sie die Sling Jobs-Konsole (https://<host>:<port>/system/console/slingevent
).
Suchen Sie die Workflow-Themen in der Konsole. Für „DAM-Update-Asset“ werden die folgenden Themen gefunden:
com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/model
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
com/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model
Erstellen Sie für jedes Thema eine Auftragswarteschlange. Erstellen Sie zu diesem Zweck eine Werkskonfiguration für den Apache Sling Job Queue Factory Service.
Die werkseitigen Konfigurationen ähneln der Granite-Workflow-Warteschlange, die unter Concurrent Workflow Processing beschrieben wird. Die Eigenschaft "Themen"stimmt jedoch mit dem Thema Ihrer Workflow-Aufträge überein.
AssetSynchronizationService
dient zur Synchronisation von Assets von gemounteten Repositorys (z. B. LiveLink, Documentum). Standardmäßig wird hierbei alle 300 Sekunden (5 Minuten) eine Prüfung durchgeführt. Wenn Sie keine installierten Repositorys verwenden, können Sie diesen Dienst deaktivieren.
Konfigurieren Sie dazu den OSGi-Dienst CQ DAM Asset Synchronization Service, sodass der Synchronisationszeitraum (scheduler.period
)(mindestens) 1 Jahr beträgt (definiert in Sekunden).
Das Bereitstellen mehrerer DAM-Instanzen kann in folgenden Fällen die Leistung steigern:
Zusätzliche Erwägungen sind:
Leistung ist von größter Bedeutung für Ihre Veröffentlichungsumgebung. Deshalb müssen Sie die Leistungstests für die Veröffentlichungsumgebung während der Implementierung Ihres Projekts sorgfältig planen und analysieren.
In diesem Abschnitt erhalten Sie einen standardisierten Überblick über die Probleme bei der Definition eines Testkonzepts speziell für Leistungstests auf Ihrer publish-Umgebung. Dies ist vor allem für QA-Beauftragte, Projektleiter und Systemadministratoren von Interesse.
Im Folgenden finden Sie einen standardisierten Ansatz für Leistungstests für eine AEM Anwendung auf der Umgebung Publish. Diese umfasst die folgenden fünf Phasen:
Die Kontrolle ist ein zusätzlicher, alles umfassender Prozess, der nötig ist, sich aber nicht auf Tests beschränkt.
Der erste Schritt besteht darin, die grundlegenden für Tests erforderlichen Informationen zu dokumentieren:
Sie sollten die Architektur der für die Leistungstests verwendeten Testumgebung genau dokumentieren.
Sie benötigen eine Reproduktion Ihrer geplanten Produktions-Veröffentlichungsumgebung gemeinsam mit dem Dispatcher und Load Balancer.
Um einen Überblick zu erhalten, können Sie ein Diagramm von der Anwendung erstellen (möglicherweise können Sie ein Diagramm von Tests in der Autorenumgebung verwenden).
Durch die Darstellung der internen Elemente der Anwendung erhalten Sie einen Überblick über die Testanforderungen. Wenn Sie Farbkodierung verwenden, können Sie dieses Diagramm auch für einen Bericht verwenden.
Eine Anwendung kann in der Regel auf vielfältige Weise eingesetzt werden. Oft sind dabei manche Anwendungsfälle wichtiger als andere.
Um den Umfang des Leistungstests speziell auf die Veröffentlichungsumgebung anzupassen, empfehlen wir Ihnen die Definition folgender Punkte:
Sie können die Anzahl von Anwendungsfällen frei wählen, sie sollte aber auf einen Wert beschränkt sein, der einfach zu handhaben ist (z. B. fünf bis zehn).
Nach der Auswahl der wichtigsten Anwendungsfälle können die KPIs (Key Performance Indicators) und die Werkzeuge für ihre Messung definiert werden. Beispiele für häufige KPIs sind:
Im Folgenden werden vier Szenarien für das Definieren und Testen der Leistungsziele beschrieben:
Es gelten die folgenden Prinzipien:
Nachdem der Umfang und die zugehörigen KPIs definiert wurden, können die spezifischen Leistungsziele festgelegt werden. Dies umfasst das Konzipieren von Testszenarien und Zielwerten.
Die Leistung muss bei durchschnittlicher Belastung und unter Spitzenlast getestet werden. Darüber hinaus müssen Sie Tests für „Going Live“-Szenarien durchführen, um zu gewährleisten, dass Ihre Website auch dem stärkeren Andrang unmittelbar nach dem Launch gewachsen ist.
Beim Festlegen künftiger Ziele können alle Erfahrungen und Statistiken von einer vorhandenen Website hilfreich sein, z. B. der maximale Datenverkehr auf Ihrer Live-Website.
Schlüsselkomponenten müssen bei durchschnittlicher Belastung und unter Spitzenlast getestet werden.
In beiden Fällen können Sie die erwartete Anzahl von Transaktionen pro Sekunde definieren, wenn eine vordefinierte Anzahl von Benutzern das System verwendet.
Komponente | Testtyp | Nein. von Benutzern | Tx/s (erwartet) | Tx/s (getestet) | Beschreibung |
---|---|---|---|---|---|
Homepage Einzelbenutzer | Durchschnitt | 1 | 1 | ||
Spitze | 3 | 3 | |||
Homepage 100 Benutzer | Durchschnitt | 100 | 1 | ||
Spitze | 100 | 1 |
Durch das Testen der kombinierten Komponenten erhalten Sie eine genauere Darstellung des Verhaltens der Anwendung. Wiederum müssen Tests bei durchschnittlicher Belastung und unter Spitzenlast durchgeführt werden.
Szenario | Komponente | Nein. von Benutzern | Tx/s (erwartet) | Tx/s (getestet) | Beschreibung |
---|---|---|---|---|---|
Gemischter Durchschnitt | Homepage | 10 | 1 | ||
Suchen | 10 | 1 | |||
Nachrichten | 10 | 2 | |||
Ereignisse | 10 | 1 | |||
Aktivierungen | 10 | 1 | Simulation des Autorenverhaltens. | ||
Gemischter Spitzenwert | Homepage | 100 | 5 | ||
Suchen | 50 | 5 | |||
Nachrichten | 100 | 10 | |||
Ereignisse | 100 | 10 | |||
Aktivierungen | 20 | 20 | Simulation des Autorenverhaltens. |
In den ersten Tagen nach dem Launch Ihrer Website ist mit erhöhtem Interesse zu rechnen. Dieses übersteigt wahrscheinlich die von Ihnen getesteten Spitzenwerte. Es wird dringend empfohlen, „Going Live“-Szenarien zu testen, um sicherzustellen, dass Ihr System einer solchen Situation gewachsen ist.
Szenario | Testtyp | Nein. von Benutzern | Tx/s (erwartet) | Tx/s (getestet) | Beschreibung |
---|---|---|---|---|---|
Live-Spitzenwert | Homepage | 200 | 20 | ||
Suchen | 100 | 10 | |||
Nachrichten | 200 | 20 | |||
Ereignisse | 200 | 20 | |||
Aktivierungen | 20 | 20 | Simulation des Autorenverhaltens. |
Fehlerszenarien müssen auch getestet werden, um sicherzustellen, dass das System ordnungsgemäß reagiert. Dies umfasst nicht nur die Handhabung eines Fehlers selbst, sondern auch die möglichen Auswirkungen eines Fehlers auf die Leistung. Beispiel:
Bei der Planung dieser Tests sollten Sie bedenken, dass nicht alle Szenarien regelmäßig auftreten. Dennoch ist ihre Auswirkung auf das gesamte System wichtig.
Fehlerszenario | Fehlertyp | Nein. von Benutzern | Tx/s (erwartet) | Tx/s (getestet) | Beschreibung |
---|---|---|---|---|---|
Überladung der Suchkomponente | Suche nach globalen Platzhaltern (Sternchen) | 10 | 3 | Nur *** durchsucht werden. | |
Wort anhalten | 20 | 2 | Suchen nach einem Stoppwort. | ||
Leere Zeichenfolge | 10 | 3 | Suchen nach einer leeren Zeichenfolge. | ||
Sonderzeichen | 10 | 1 | Suchen nach Sonderzeichen |
Gewisse Probleme treten erst auf, wenn das System über einen längeren Zeitraum hinweg aktiv war. Das können Stunden oder sogar Tage sein. Mit einem Belastungstest wird eine konstante durchschnittliche Belastung während eines bestimmten Zeitraums getestet. Danach kann ein etwaiger Leistungsabfall untersucht werden.
Szenario | Testtyp | Nein. von Benutzern | Tx/s (erwartet) | Tx/s (getestet) | Beschreibung |
---|---|---|---|---|---|
Dauerprüfung (72 Stunden) | Homepage | 10 | 3 | ||
Suchen | 10 | 3 | |||
Nachrichten | 20 | 2 | |||
Ereignisse | 10 | 1 | |||
Aktivierungen | 1 | 1 | Simulation des Autorenverhaltens. |
In den späteren Implementierungsphasen werden Sie die Anwendung optimieren müssen, um die Leistungsziele zu erreichen bzw. zu maximieren.
Alle vorgenommenen Optimierungen müssen auf folgende Bedingungen hin getestet werden:
Für die Lastgenerierung, Leistungsüberwachung und/oder Ergebnisanalyse steht eine Reihe von Tools zur Verfügung:
Nach der Optimierung müssen Sie einen erneuten Test durchführen, um die Auswirkungen zu überprüfen.
Es wird ein laufender Berichte benötigt, um jeden über den Status zu informieren, wie bereits erwähnt mit der Farbcodierung, kann die Architektur-Map dafür verwendet werden.
Nachdem alle Tests abgeschlossen sind, können Sie Berichte über folgende Bereiche erstellen:
Der Dispatcher ist das Caching- und/oder Lastausgleichs-Tool von Adobe. Bei Verwendung des Dispatchers sollten Sie Ihre Website hinsichtlich der Cache-Leistung optimieren.
Dispatcher-Versionen sind unabhängig von AEM, die Dispatcher-Dokumentation ist jedoch in die AEM-Dokumentation eingebettet. Verwenden Sie immer die Dispatcher-Dokumentation, die in der Dokumentation für die neueste Version von AEM eingebettet ist.
Möglicherweise wurden Sie von der Dispatcher-Dokumentation zu einer früheren AEM-Version zu dieser Seite weitergeleitet.
Der Dispatcher bietet verschiedene integrierte Mechanismen zur Optimierung der Leistung Ihrer Website. In diesem Abschnitt erfahren Sie, wie Sie Ihre Website einrichten, um die Vorteile der Zwischenspeicherung zu maximieren.
Beachten Sie dabei, dass der Dispatcher den Cache auf einem Standardwebserver speichert. Dies bedeutet, dass Sie:
Allgemein müssen für viele Caching-Strategien geeignete URLs ausgewählt werden, damit diese zusätzlichen Daten nicht benötigt werden.
Mit Dispatcher Version 4.1.11 können Sie auch Antwort-Kopfzeilen zwischenspeichern, siehe Zwischenspeichern von HTTP-Antwort-Kopfzeilen.
Mit der Cache-Verhältnis-Formel wird der ungefähre Prozentsatz der vom Cache gehandhabten Anforderungen verglichen mit der Gesamtzahl der Systemanforderungen berechnet. Zur Berechnung des Cache-Verhältnisses benötigen Sie Folgendes:
Die Gesamtzahl der Anforderungen. Diese Information können Sie der Apache-Datei access.log
entnehmen. Weitere Informationen finden Sie in der offiziellen Apache-Dokumentation.
Die Anzahl der von der Veröffentlichungsinstanz gehandhabten Anforderungen. Diese Informationen sind im Ordner request.log
der Instanz verfügbar. Weitere Informationen finden Sie unter Interpretieren der Datei request.log und Suchen der Protokolldateien.
Die Formel zur Berechnung des Cache-Verhältnisses lautet:
Beispiel: Die Gesamtzahl der Anforderungen ist 129491 und die Anzahl der von der Veröffentlichungsinstanz gehandhabten Anforderungen ist 58959. Das Cache-Verhältnis beträgt daher: (129491 - 58959) : 129491 = 54,5 %.
Wenn es keine direkte Entsprechung zwischen Publisher und Dispatcher gibt, müssen Sie die Anforderungen von allen Dispatchern und Publishern addieren, um eine korrekte Messung zu erhalten. Siehe auch Empfohlene Bereitstellungen.
Für eine optimale Leistung empfiehlt Adobe ein Cache-Verhältnis von 90 % bis 95 %.
Mit der Dispatcher-Version 4.1.11 können Sie Antwort-Header cachen. Wenn Sie keine Antwort-Header im Dispatcher cachen, können Probleme auftreten, wenn Sie in der Kopfzeile Seitenkodierungsinformationen speichern. Wenn der Dispatcher in diesem Fall eine Seite aus dem Cache bereitstellt, wird die Standardkodierung des Webservers für die Seite verwendet. Es gibt zwei Möglichkeiten, um dieses Problem zu vermeiden:
<META>
-Tag im HTML-Abschnitt head
, um die Codierung festzulegen. Beispiel: <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
Vermeiden Sie, wenn möglich, URL-Parameter für Seiten, die Sie zwischenspeichern möchten. Wenn Sie beispielsweise eine Bildergalerie betrachten, wird die folgende URL nie zwischengespeichert (es sei denn, der Dispatcher wurde entsprechend konfiguriert):
www.myCompany.com/pictures/gallery.html?event=christmas&page=1
Sie können diese Parameter allerdings in der URL der Seite platzieren:
www.myCompany.com/pictures/gallery.christmas.1.html
Diese URL ruft dieselbe Seite und dieselbe Vorlage wie gallery.html
auf. In der Vorlagendefinition können Sie angeben, welches Skript die Seite rendern soll, oder Sie können ein Skript für alle Seiten verwenden.
Wenn Sie Benutzern die Möglichkeit geben, die Schriftgröße zu ändern (oder andere Layoutanpassungen vorzunehmen), stellen Sie sicher, dass die verschiedenen Anpassungen in der URL repräsentiert werden.
Beispielsweise werden Cookies nicht zwischengespeichert. Wenn Sie also die Schriftgröße in einem Cookie (oder einem ähnlichen Mechanismus) speichern, bleibt die Schriftgröße für die zwischengespeicherte Seite nicht erhalten. Daher gibt der Dispatcher Dokumente mit beliebiger Schriftgröße nach dem Zufallsprinzip zurück.
Wenn Sie die Schriftgröße in der URL als Selektor einschließen, wird dieses Problem vermieden:
www.myCompany.com/news/main.large.html
Bei den meisten Layoutkomponenten können auch Stylesheets und/oder clientseitige Skripts verwendet werden. Diese funktionieren normalerweise gut mit dem Zwischenspeichern.
Dies ist auch für Druckversionen nützlich, für die Sie eine URL wie in diesem Beispiel erstellen können:
www.myCompany.com/news/main.print.html
Unter Verwendung des Skript-Globbings der Vorlagendefinition können Sie ein anderes Skript festlegen, das die Seiten für das Drucken anzeigt.
Wenn Sie Seitentitel oder anderen Text als Grafik rendern, sollten Sie die Dateien speichern, damit sie nach einer Inhaltsaktualisierung auf der Seite gelöscht werden:
Platzieren Sie die Bilddatei im selben Verzeichnis wie die Seite.
Verwenden Sie das folgende Namensformat für die Bilddatei:
<page file name>.<image file name>
Sie können beispielsweise den Titel der Seite myPage.html
in file myPage.title.gif
speichern. Diese Datei wird automatisch gelöscht, wenn die Seite aktualisiert wird. Alle Änderungen des Seitentitels werden daher automatisch im Cache übernommen.
Die Bilddatei ist nicht unbedingt tatsächlich in der AEM-Instanz vorhanden. Sie können ein Skript verwenden, das die Bilddatei dynamisch erstellt. Der Dispatcher speichert die Datei dann auf dem Webserver.
Wenn Sie Bilder als Navigationseinträge verwenden, gehen Sie im Prinzip wie bei Titeln vor, das Verfahren ist nur etwas komplexer. Speichern Sie alle Navigationsgrafiken mit den Zielseiten. Wenn Sie zwei Bilder für den normalen und aktiven Status verwenden, können Sie die folgenden Skripts verwenden:
Sie müssen diese Grafiken mit demselben Namenhandle wie die Seite erstellen, um sicherzustellen, dass bei einer Inhaltsaktualisierung diese Bilder sowie die Seite gelöscht werden.
Bei Seiten, die nicht geändert werden, bleiben die Bilder im Cache, auch wenn die Seiten selbst normalerweise automatisch ungültig gemacht werden.
Es wird empfohlen, die Personalisierung auf den erforderlichen Bereich zu beschränken. Dies hat folgende Gründe:
Weitere Informationen zum Konfigurieren des Dispatcher-Cache finden Sie im Lehrgang AEM Dispatcher-Cache und im Abschnitt Zwischenspeichern geschützter Inhalte.
Wenn Sie jede Seite personalisieren (z. B. indem Sie den Namen des Benutzers in die Titelleiste setzen), kann dies Auswirkungen auf die Leistung haben.
Informationen zum Zwischenspeichern geschützter Inhalte finden Sie unter Zwischenspeichern von geschütztem Inhalt im Dispatcher-Handbuch.
In Bezug auf das Mischen von eingeschränktem und öffentlichem Inhalt auf einer Seite sollten Sie eine Strategie in Betracht ziehen, die serverseitige Einschlüsse im Dispatcher nutzt, oder clientseitige Einschlüsse über Ajax im Browser.
Informationen zum Umgang mit gemischten öffentlichen und eingeschränkten Inhalten finden Sie unter Sling Dynamic Include einrichten.
Sticky-Verbindungen stellen sicher, dass alle Dokumente für einen Benutzer auf demselben Server erstellt werden. Wenn ein Benutzer dieses Verzeichnis verlässt und später zurückkehrt, bleibt die Verbindung erhalten. Definieren Sie einen Ordner für alle Dokumente, die Sticky-Verbindungen für die Website benötigen. Speichern Sie möglichst keine anderen Dokumente in diesem Ordner. Dies wirkt sich auf den Lastenausgleich aus, wenn Sie personalisierte Seiten und Sitzungsdaten verwenden.
Es gibt zwei Möglichkeiten, wie ein Browser den Typ einer Datei bestimmen kann:
.html
, .gif
, .jpg
usw.)Für die meisten Dateien wird der MIME-Typ durch die Dateierweiterung angegeben :
.html
, .gif
, .jpg
usw.)Wenn der Dateiname keine Erweiterung aufweist, wird er als einfacher Text dargestellt.
Mit der Dispatcher-Version 4.1.11 können Sie Antwort-Header cachen. Wenn Sie keine Antwort-Header im Dispatcher cachen, beachten Sie, dass der Mime-Typ Bestandteil der HTTP-Kopfzeile ist. Wenn Ihre AEM-Anwendung daher Dateien zurückgibt, die kein erkanntes Dateiende haben und stattdessen den MIME-Typ verwenden, werden diese Dateien möglicherweise falsch angezeigt.
Um sicherzustellen, dass Dateien richtig zwischengespeichert werden, halten Sie sich an die folgenden Richtlinien.
download.jsp?file=2214
enthalten. Schreiben Sie das Skript erneut, um URLs mit der Dateispezifikation zu verwenden. Im vorherigen Beispiel wäre dies download.2214.pdf
.In diesem Abschnitt werden eine Reihe von Benchmarks vorgestellt, mit denen die Leistung AEM Backups und die Auswirkungen der Backup-Aktivität auf die Anwendungsleistung bewertet werden. AEM Backups stellen während der Ausführung eine erhebliche Belastung des Systems dar, und wir messen dies sowie die Auswirkungen der Backup-Verzögerung-Einstellungen, die versuchen, diese Effekte zu modulieren. Ziel dabei ist es, Referenzdaten zur erwarteten Sicherungsleistung bei realistischen Konfigurationen und Produktionsdatenmengen zu erhalten. Außerdem soll eine Orientierungshilfe zur Schätzung der Sicherungsdauer in geplanten Systemen geboten werden.
Die in diesem Dokument genannten Ergebnisse stammen von Benchmarks, die in einer Referenzumgebung ausgeführt wurden und die folgende Konfiguration aufweisen. Diese Konfiguration ähnelt einer typischen Produktions-Umgebung in einem Rechenzentrum:
Das Plattensubsystem auf diesem Server ist relativ schnell und entspricht einer leistungsstarken RAID-Konfiguration, die auf einem Produktionsserver verwendet werden könnte. Die Leistung bei der Sicherung hängt von der Leistung der Festplatten ab und die Ergebnisse in dieser Umgebung spiegeln die Leistung einer extrem schnellen RAID-Konfiguration wider. Das VMWare-Abbild wird als ein einziger großer Datenträger konfiguriert, der sich physisch im lokalen Plattenspeicher im RAID-Array befindet.
Die AEM Konfiguration legt das Repository und den Datenspeicher auf demselben logischen Volume zusammen mit dem gesamten Betriebssystem und AEM Software ab. Auch das Zielverzeichnis für Sicherungen befindet sich in diesem logischen Dateisystem.
In der folgenden Tabelle werden die für die Sicherungs-Benchmarks verwendeten Datenmengen dargestellt. Zunächst wird der ursprüngliche Inhalt installiert, danach werden weitere bekannte Datenmengen hinzugefügt, um die Größe des gesicherten Inhalts zu steigern. Sicherungen werden in Inkrementen erstellt, um einen starken Inhaltszuwachs und die produzierte Tagesmenge nachzubilden. Die Verteilung der Inhalte (Seiten, Bilder, Tags) entspricht in etwa einer realistischen Asset-Zusammensetzung. Seiten, Bilder und Tags sind auf maximal 800 untergeordnete Seiten beschränkt. Jede Seite enthält Titel-, Flash-, Text/Bild-, Video-, Diashow-, Formular-, Tabellen-, Cloud- und Karussellkomponenten. Bilder werden aus einem Pool von 400 Dateien hochgeladen, deren Größe von 37 KB bis 594 KB reicht.
Inhalt | Knoten | Seiten | Bilder | Tags |
---|---|---|---|---|
Basisinstallation | 69.610 | 562 | 256 | 237 |
Kleine Inhalte für die inkrementelle Sicherung | +100 | +2 | +2 | |
Große Inhalte für vollständige Sicherung | +10 000 | +100 | +100 |
Die Backup-Benchmark wird bei jeder Wiederholung mit den zusätzlichen Inhaltssätzen wiederholt.
Die Sicherungs-Benchmarks beziehen sich auf zwei Hauptszenarien: Sicherungen bei hoher Anwendungslast und Sicherungen bei inaktivem System. Obwohl die allgemeine Empfehlung lautet, dass Backups durchgeführt werden sollten, wenn AEM so untätig wie möglich ist, gibt es Situationen, in denen die Sicherung ausgeführt werden muss, wenn das System unter Belastung ist.
Die Sicherungszeiten und die Größe der resultierenden Sicherung werden aus den AEM-Serverprotokollen abgerufen. Es wird normalerweise empfohlen, Backups für Nebenzeiten zu planen, wenn AEM untätig ist, z. B. mitten in der Nacht. Dieses Szenario entspricht der empfohlenen Vorgehensweise.
Die Last besteht aus Seitenerstellungen/-löschungen, Traversierungen und Anforderungen, wobei der Großteil der Last von Traversierungen und Anforderungen stammt. Wenn laufend zu viele Seiten hinzugefügt und entfernt werden, wird die Größe des Arbeitsbereichs erhöht und Sicherungen können nicht durchgeführt werden. Die vom Skript verwendete Lastverteilung besteht aus 75 % Traversierungen, 24 % Anforderungen und 1 % Seitenerstellung (nur eine Ebene ohne verschachtelte Unterseiten). Die größte Anzahl an durchschnittlichen Transaktionen pro Sekunde in einem inaktiven System wird mit vier gleichzeitigen Threads erzielt, wie sie auch beim Testen von Sicherungen unter Last verwendet werden.
Die Auswirkung von Last auf die Sicherungsleistung kann geschätzt werden, indem die Differenz zwischen der Leistung mit Anwendungslast und der Leistung ohne Anwendungslast errechnet wird. Die Auswirkung der Sicherung auf den Anwendungsdurchsatz können Sie ermitteln, indem Sie den Durchsatz des Szenarios in Transaktionen pro Stunde mit und ohne gleichzeitige Sicherung mit Sicherungen vergleichen, die mit unterschiedlichen Verzögerungseinstellungen ausgeführt werden.
Als Hauptergebnis dieser Benchmarks kann gezeigt werden, wie die Sicherungsdauer je nach Sicherungstyp und Datenmenge variiert. Das folgende Diagramm zeigt die erfasste Sicherungsdauer bei der Standard-Sicherungskonfiguration als eine Funktion der Seitenzahl.
Die Sicherungsdauer in einer inaktiven Instanz ist relativ konstant und beträgt im Schnitt 0,608 MB/s unabhängig davon, ob es sich um eine vollständige oder inkrementelle Sicherung handelt (siehe Diagramm unten). Die Sicherungsdauer ist einfach eine Funktion der gesicherten Datenmenge. Die Dauer einer vollständigen Sicherung nimmt eindeutig mit der Seitenzahl zu. Auch die Dauer einer inkrementellen Sicherung nimmt mit der Seitenzahl zu, aber in einem wesentlich geringeren Ausmaß. Die Dauer einer inkrementellen Sicherung ist aufgrund der relativ kleinen Datenmenge wesentlich kürzer.
Die Größe der erzeugten Sicherung ist entscheidend für die Sicherungsdauer. Das folgende Diagramm zeigt die Dauer als Funktion der Sicherungsgröße.
Dieses Diagramm zeigt, dass sowohl inkrementelle als auch vollständige Sicherungen einem einfachen Größe-Dauer-Verhältnis folgen, das wir als Durchsatz messen können. Die Sicherungsdauer in einer inaktiven Instanz ist relativ konstant und beträgt im Schnitt 0,61 MB/s unabhängig davon, ob es sich um eine vollständige oder inkrementelle Sicherung in der Benchmark-Umgebung handelt.
Mit dem Sicherungsverzögerungsparameter können Sie das Ausmaß beschränken, bis zu dem Produktionsaufgaben durch Sicherungen beeinträchtigt werden. Der Parameter gibt eine Wartezeit in Millisekunden an, die für jede Datei beim Sicherungsvorgang eingefügt wird. Die Wirkung hängt zum Teil von der Größe der jeweiligen Dateien ab. Durch das Messen der Sicherungsleistung in MB/s können die Auswirkungen der Verzögerung auf den Sicherungsvorgang verglichen werden.
Zum Vergleich wurde der Durchsatz bei der Sicherung derselben Repository-Dateien mit einer Dateisystemsicherung (mit „tar“) geprüft. Die Leistung mit dem tar-Befehl ist vergleichbar, aber etwas höher als die Sicherung mit der mit null festgelegten Verzögerung. Wenn auch nur eine geringe Verzögerung ausgewählt wird, wird der Sicherungsdurchsatz stark reduziert. Die Standardverzögerung von 10 ms ergibt einen deutlich verringerten Durchsatz. Wenn eine Sicherung zu Zeiten geplant werden kann, in denen die Anwendung wenig ausgelastet oder völlig inaktiv ist, ist es empfehlenswert, die Verzögerung unter den Standardwert zu senken, damit die Sicherung schneller durchgeführt werden kann.
Die tatsächliche Auswirkung des Anwendungsdurchsatzes auf eine aktive Sicherung hängt von der Anwendung und der Infrastruktur ab. Die Auswahl des Verzögerungswerts sollte auf der Basis einer empirischen Analyse der Anwendung erfolgen, er sollte aber möglichst gering sein, damit Sicherungen so schnell wie möglich durchgeführt werden können. Da es nur eine schwache Korrelation zwischen der Wahl des Verzögerungswerts und der Auswirkung auf den Anwendungsdurchsatz gibt, sollte bei der Auswahl der Verzögerung eine kürzere Sicherungsdauer bevorzugt werden, um die Auswirkungen einer Sicherung zu minimieren. Eine Sicherung, die acht Stunden dauert, aber den Durchsatz um 20 % verringert, wirkt sich wahrscheinlich insgesamt stärker aus als eine Sicherung, die zwei Stunden dauert, aber den Durchsatz um 30 % verringert.