Leistungsoptimierung performance-optimization

Ein wichtiger Faktor ist die Zeit, die Ihre Website benötigt, um auf Anforderungen durch Besucher zu reagieren. Dieser Wert variiert zwar für jede Anforderung, es kann jedoch ein durchschnittlicher Zielwert definiert werden. Sobald sich gezeigt hat, dass dieser Wert sowohl erreichbar als auch wartbar ist, kann er verwendet werden, um die Leistung der Website zu überwachen und die Entwicklung potenzieller Probleme anzuzeigen.

Die Antwortzeiten, die Sie anstreben, unterscheiden sich in der Autoren- und Veröffentlichungsumgebung und spiegeln die verschiedenen Merkmale der Zielgruppe wider:

Autorenumgebung author-environment

Diese Umgebung wird von Autoren verwendet, die Inhalte eingeben und aktualisieren. Sie muss für eine kleine Anzahl von Benutzern ausgelegt sein, die bei der Aktualisierung von Inhaltsseiten und einzelnen Elementen auf diesen Seiten jeweils eine hohe Anzahl leistungsintensiver Anforderungen generieren.

Veröffentlichungsumgebung publish-environment

Diese Umgebung enthält Inhalte, die Sie Ihren Benutzern zur Verfügung stellen. In dieser Umgebung ist die Anzahl der Anfragen sogar noch höher, während die Geschwindigkeit genauso wichtig ist. Doch da die Anfragen weniger dynamisch sind, können Methoden zur zusätzlichen Leistungssteigerung angewendet werden. Hierzu zählen das Caching des Inhalts und der Lastenausgleich.

Methode zur Leistungsoptimierung performance-optimization-methodology

Beachten Sie diese fünf einfachen Regeln zur Leistungsoptimierung von AEM-Projekten, um Probleme von Anfang an zu vermeiden:

Diese Regeln gelten für Webprojekte im Allgemeinen. Projektleitende und Systemadmins können damit gewährleisten, dass ihre Projekte keine Leistungsprobleme haben, wenn der Startzeitpunkt gekommen ist.

Zeit für die Optimierung einplanen planning-for-optimization

Etwa 10 % der Projektbemühungen sollten für die Leistungsoptimierungsphase geplant werden. Die tatsächlichen Anforderungen an die Leistungsoptimierung hängen natürlich von der Komplexität eines Projekts und der Erfahrung des Entwicklungsteams ab. Obwohl Ihr Projekt (letztendlich) nicht die gesamte zugewiesene Zeit benötigt, empfiehlt es sich, immer die Leistungsoptimierung in der vorgeschlagenen Region zu planen.

Wenn möglich sollte ein Projekt zunächst probeweise für eine begrenzte Zielgruppe gestartet werden, um Erfahrungen i, praktischen Betrieb zu sammeln und weitere Optimierungen vorzunehmen. Dadurch wird zusätzlicher Druck vermieden, der mit einer Ankündigung des vollständigen Launches einhergeht.

Sobald Sie "live"sind, ist die Leistungsoptimierung nicht mehr vorbei. Dies ist der Zeitpunkt, zu dem Sie die "tatsächliche"Belastung Ihres Systems erleben. Es ist wichtig, nach dem Start zusätzliche Anpassungen zu planen.

Da sich die Systemlast ändert und sich die Leistungsprofile Ihres Systems im Laufe der Zeit verändern, sollte in Intervallen von 6 bis 12 Monaten eine Leistungsoptimierung oder Konsistenzprüfung geplant werden.

Reale Situationen simulieren simulate-reality

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 Realität nachzubilden ist schwierig und wie viel Aufwand Sie dafür betreiben möchten, hängt von der Art Ihres Projekts ab. "Real"bedeutet nicht nur "echter Code"und "echter Traffic", sondern auch "realer Inhalt", insbesondere in Bezug auf Inhaltsgröße und -struktur. Beachten Sie, dass sich Ihre Vorlagen je nach Größe und Struktur des Repositorys möglicherweise völlig anders verhalten.

Konkrete Ziele festlegen establish-solid-goals

Die Bedeutung konkreter Leistungsziele sollte nicht unterschätzt werden. Wenn Personen einmal bestimmte Leistungsziele festgelegt haben, ist es sehr schwer, diese zu ändern, auch wenn sie nur auf vagen Annahmen beruhen.

Die Festlegung guter, solider Leistungsziele ist wirklich einer der schwierigsten Bereiche. Oft ist es am besten, von einer vergleichbaren Website (z. B. dem Vorgänger der neuen Website) reale Lebensprotokolle und Benchmarks zu sammeln.

Relevante Maßnahmen treffen stay-relevant

Es ist wichtig, jeweils einen Engpass zu optimieren. Wenn Sie versuchen, Dinge parallel zu erledigen, ohne die Auswirkungen einer Optimierung zu überprüfen, verlieren Sie den Überblick darüber, welche Optimierungsmaßnahme tatsächlich geholfen hat.

Agile Iterationszyklen agile-iteration-cycles

Im Zuge der Leistungsanpassung werden Werte immer wieder gemessen, analysiert, optimiert und validiert, bis der Zielwert erreicht ist. Deshalb ist es besser, in die Optimierungsphase einen agilen Validierungsprozess einzubauen als nach jeder Iteration umfangreiche Tests durchzuführen.

Dies bedeutet im Wesentlichen, dass der Entwickler, der die Optimierung implementiert, schnell feststellen kann, ob die Optimierung bereits das Ziel erreicht hat. Dies sind wertvolle Informationen, da die Optimierung bei Erreichen des Ziels vorbei ist.

Allgemeine Leistungsrichtlinien basic-performance-guidelines

Im Allgemeinen sollten nicht gecachte HTML-Anforderungen weniger als 100 ms benötigen. Konkret wird Folgendes empfohlen:

Die obigen Zahlen gehen von folgenden Bedingungen aus:

Es gibt eine Reihe von Problemen, die häufig zu Leistungsproblemen beitragen. Diese drehen sich hauptsächlich um:

JVM- und Betriebssystemebenen-Optimierungen führen normalerweise nicht zu großen Leistungssteigerungen und sollten daher am Ende des Optimierungszyklus durchgeführt werden.

Die Art und Weise, wie ein Content-Repository strukturiert ist, kann sich auch auf die Leistung auswirken. Für eine optimale Leistung sollte die Anzahl der untergeordneten Knoten, die an einzelne Knoten in einem Inhalts-Repository angehängt werden, 1.000 nicht überschreiten (in der Regel).

Ihre besten Freunde während einer üblichen Leistungsoptimierungsübung sind:

Leistung beim Laden und Bearbeiten digitaler Assets performance-when-loading-and-editing-digital-assets

Aufgrund der großen Datenmenge, die beim Laden und Bearbeiten digitaler Assets benötigt wird, kann die Leistung zu einem Problem werden.

Zwei Dinge wirken sich auf die Leistung aus:

Um die Leistung zu verbessern, sollten Sie Folgendes beachten:

Performance-Überwachung performance-monitoring

Die Leistung (oder das Fehlen) ist eines der ersten Dinge, die Ihre Benutzer bemerken. Wie bei jeder Anwendung mit einer Benutzeroberfläche ist die Leistung von entscheidender Bedeutung. Um die Leistung Ihrer AEM-Installation zu optimieren, müssen Sie verschiedene Attribute der Instanz und ihr Verhalten überwachen.

Weitere Informationen zur Leistungsüberwachung finden Sie unter Überwachen der Leistung.

Die Probleme, die Leistungsprobleme verursachen, lassen sich oft nur schwer nachvollziehen, selbst wenn ihre Auswirkungen leicht erkennbar sind.

Ein grundlegender Ausgangspunkt ist ein gutes Wissen über Ihr System, wenn es normal arbeitet. Wenn Sie nicht wissen, wie Ihre Umgebung bei ordnungsgemäßer Ausführung "aussieht"und "sich"verhält, kann es schwierig sein, das Problem zu finden, wenn sich die Leistung verschlechtert. Das bedeutet, dass Sie etwas Zeit darauf verwenden sollten, Ihr System zu untersuchen, wenn es reibungslos läuft, und sicherstellen, dass die Erfassung von Leistungsinformationen eine fortlaufende Aufgabe ist. Dies bietet Ihnen eine Vergleichsgrundlage für den Fall, dass die Leistung beeinträchtigt wird.

Das folgende Diagramm veranschaulicht den möglichen Pfad von AEM-Inhalten, und damit die Anzahl der unterschiedlichen Elemente, die die Leistung beeinflussen können.

Leistung wird auch durch das Verhältnis zwischen Volumen und Kapazität bestimmt:

Lautstärke Die Menge der Ausgabe, die vom System verarbeitet und bereitgestellt wird.

Kapazität Die Fähigkeit des Systems, das Volumen bereitzustellen.

Dies kann an unterschiedlichen Stellen des Web-Pfads veranschaulicht werden.

Es gibt verschiedene Funktionsbereiche, die häufig für die Leistungsbeeinträchtigung verantwortlich sind:

Grundregeln für die Leistung basic-rules-regarding-performance

Bei der Leistungsoptimierung sollten bestimmte Regeln beachtet werden:

Konfiguration zur Leistungsoptimierung configuring-for-performance

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.

Suchindizierung search-indexing

Ab AEM 6.0 verwendet Adobe Experience Manager eine Oak-basierte Repository-Architektur.

Die aktualisierten Indizierungsinformationen finden Sie hier:

Gleichzeitige Verarbeitung von Workflows concurrent-workflow-processing

Schränken Sie die Anzahl der gleichzeitig ausgeführten Workflow-Prozesse ein, um die Leistung zu verbessern. Standardmäßig verarbeitet die Workflow-Engine so viele Workflows parallel wie Prozessoren, die für die Java-VM verfügbar sind. Wenn Workflow-Schritte große Mengen von Verarbeitungsressourcen (RAM oder CPU) erfordern, kann es vorkommen, dass durch das gleichzeitige Ausführen mehrerer dieser Workflows die Serverressourcen stark beansprucht werden.

Wenn beispielsweise Bilder (oder DAM-Assets im Allgemeinen) hochgeladen werden, importieren Workflows die Bilder automatisch in DAM. Bilder sind häufig hochauflösend und können problemlos Hunderte von MB Heap für die Verarbeitung verbrauchen. Die parallele Handhabung dieser Bilder stellt eine hohe Belastung des Speicher-Subsystems und des Speicherbereinigers dar.

Die Workflow-Engine verwendet Apache Sling-Auftragswarteschlangen für die Verarbeitung und Planung der Verarbeitung von Arbeitselementen. Die folgenden Auftragswarteschlangendienste wurden standardmäßig in der Apache Sling Job Queue Configuration Service Factory zur Verarbeitung von Workflow-Aufgaben erstellt:

Konfigurieren Sie diese Dienste, um die maximale Anzahl der parallel ausgeführten Workflow-Prozesse zu beschränken.

Hinweis: Die Konfiguration dieser Auftragswarteschlangen wirkt sich auf alle Workflows aus, es sei denn, Sie haben eine Auftragswarteschlange für ein bestimmtes Workflow-Modell erstellt (siehe Konfigurieren der Warteschlange für ein bestimmtes Workflow-Modell unten).

Konfiguration im Repository configuration-in-the-repo

Wenn Sie die Dienste mithilfe eines sling:OsgiConfig-Knotens konfigurieren, müssen Sie den PID der vorhandenen Dienste suchen, zum Beispiel: org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Sie können den PID mithilfe der Webkonsole ermitteln.

Sie müssen die Eigenschaft mit dem Namen queue.maxparallel konfigurieren.

Konfiguration in der Web-Konsole configuration-in-the-web-console

Um diese Dienste mithilfe der Web-Konsole zu konfigurieren, suchen Sie die vorhandenen Konfigurationselemente unter der Apache Sling Job Queue Configuration Service Factory.

Konfigurieren Sie die Eigenschaft „Maximale parallele Aufträge“.

Konfigurieren der Warteschlange für einen spezifischen Workflow configure-the-queue-for-a-specific-workflow

Erstellen Sie eine Auftragswarteschlange für ein bestimmtes Workflow-Modell, damit Sie die Auftragsverarbeitung für dieses Workflow-Modell konfigurieren können. Auf diese Weise beeinflussen Ihre Konfigurationen die Verarbeitung für einen bestimmten Workflow, während die Konfiguration der standardmäßigen Granite-Workflow-Warteschlange die Verarbeitung anderer Workflows steuert.

Wenn Workflow-Modelle ausgeführt werden, erstellen sie Sling-Aufträge für ein bestimmtes Thema. Standardmäßig stimmt das Thema mit den Themen überein, die für die allgemeine Granite-Workflow-Warteschlange oder die Granite-Workflow-Warteschlange für externe Prozessaufträge konfiguriert sind:

Die tatsächlich von Workflow-Modellen erstellten Auftragsthemen enthalten modellspezifische Suffixe. Beispielsweise erzeugt 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 wird ein Workflow DAM Update Asset als Beispiel verwendet, um eine Auftragswarteschlange für einen Workflow zu erstellen.

AEM DAM Asset-Synchronisierungsdienst cq-dam-asset-synchronization-service

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).

Mehrere DAM-Instanzen multiple-dam-instances

Das Bereitstellen mehrerer DAM-Instanzen kann in folgenden Fällen die Leistung steigern:

Zusätzliche Erwägungen sind:

Best Practices zur Qualitätssicherung best-practices-for-quality-assurance

Die Leistung ist für Ihre Veröffentlichungsumgebung von größter Bedeutung. Daher müssen Sie die Leistungstests, die Sie für die Veröffentlichungsumgebung durchführen, während Sie Ihr Projekt implementieren, sorgfältig planen und analysieren.

In diesem Abschnitt erhalten Sie einen Überblick über Probleme bei der Definition eines Testkonzepts speziell für Leistungstests in der Veröffentlichungsumgebung. Dies ist vor allem für QA-Beauftragte, Projektleitende und Systemadmins von Interesse.

Im Folgenden wird die übliche Vorgehensweise bei der Durchführung von Leistungstests bei einer AEM-Anwendung in der Veröffentlichungsumgebung beschrieben. Diese umfasst die folgenden fünf Phasen:

Die Steuerung ist ein zusätzlicher, allumfassender Prozess - notwendig, aber nicht auf Tests beschränkt.

Überprüfung des Wissens verification-of-knowledge

Ein erster Schritt besteht darin, die grundlegenden Informationen zu dokumentieren, die Sie vor dem Testen benötigen:

Testarchitektur test-architecture

Sie sollten die Architektur der Testumgebung, die für Ihre Leistungstests verwendet wird, klar dokumentieren.

Sie benötigen eine Wiedergabe der geplanten Veröffentlichungsumgebung in der Produktion, zusammen mit dem Dispatcher und dem Load Balancer.

App Map application-map

Um einen klaren Überblick zu erhalten, können Sie eine Karte der gesamten Anwendung erstellen (dies kann auch aus Tests in der Autorenumgebung erfolgen).

Eine Diagrammdarstellung der internen Elemente der Anwendung kann einen Überblick über die Prüfanforderungen geben. mit Farbkodierung kann es auch als Grundlage für die Berichterstellung dienen.

Definition des Umfangs scope-definition

Eine Anwendung verfügt in der Regel über eine Auswahl von Anwendungsfällen. Einige werden sehr wichtig sein, andere weniger.

Um den Umfang der Leistungstests auf die Veröffentlichung zu fokussieren, empfehlen wir, Folgendes zu definieren:

Die Anzahl der Anwendungsfälle liegt bei Ihnen, sollte jedoch auf eine leicht verwaltbare Zahl (z. B. zwischen 5 und 10) beschränkt sein.

Sobald die wichtigsten Anwendungsfälle ausgewählt sind, können die wichtigsten Leistungsindikatoren (Key Performance Indicators, KPI) und die Tools, mit denen sie gemessen werden, für jeden Fall definiert werden. Beispiele für häufig verwendete KPIs:

Testmethoden test-methodologies

Dieses Konzept umfasst vier Szenarien, die zum Definieren und Testen der Leistungsziele verwendet werden:

Basierend auf den folgenden Grundsätzen.

Belastungsgrenze der Komponente component-breakpoints

Transaktionen transactions

Leistungsziele definieren defining-the-performance-goals

Sobald der Umfang und die zugehörigen KPIs definiert wurden, können die spezifischen Leistungsziele festgelegt werden. Dazu müssen Testszenarien zusammen mit Zielwerten entwickelt werden.

Sie müssen die Leistung sowohl unter durchschnittlichen als auch unter Spitzenbedingungen testen. Darüber hinaus benötigen Sie Going Live-Szenario-Tests, um sicherzustellen, dass Sie bei der erstmaligen Bereitstellung der Website für ein erhöhtes Interesse sorgen können.

Jede Erfahrung oder Statistik, die Sie auf einer vorhandenen Website gesammelt haben, kann auch bei der Bestimmung künftiger Ziele nützlich sein. Beispiel: Top-Traffic von Ihrer Live-Website.

Tests einzelner Komponenten single-component-tests

Kritische Komponenten müssen sowohl unter durchschnittlichen als auch unter Spitzenbedingungen 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.

Kombinierte Komponententests combined-component-tests

Durch das Testen der Komponenten in Kombination wird das Anwendungsverhalten besser widergespiegelt. Auch hier müssen die durchschnittlichen und Spitzenbedingungen getestet werden.

Ausführen von Live-Tests going-live-tests

In den ersten Tagen nach der Bereitstellung Ihrer Website können Sie mit einem erhöhten Interesse rechnen. Dies wird wahrscheinlich noch größer sein als die Spitzenwerte, auf die Sie getestet haben. Es wird dringend empfohlen, "Going Live"-Szenarien zu testen, um sicherzustellen, dass das System diese Situation bewältigen kann.

Fehlerszenario-Tests error-scenario-tests

Fehlerszenarien müssen ebenfalls getestet werden, um sicherzustellen, dass das System richtig und angemessen reagiert. Nicht nur in der Art und Weise, wie der Fehler selbst gehandhabt wird, sondern auch in den Auswirkungen, die er auf die Leistung haben kann. Beispiel:

Bei der Konzeption dieser Tests sollte beachtet werden, dass nicht alle Szenarien regelmäßig durchgeführt werden. Ihre Auswirkungen auf das gesamte System sind jedoch wichtig.

Belastungstests endurance-tests

Bestimmte Probleme treten erst auf, nachdem das System über einen ununterbrochenen Zeitraum ausgeführt wurde. entweder Stunden oder sogar Tage. Mit einem Dauertest wird eine konstante durchschnittliche Belastung über einen bestimmten Zeitraum getestet. Jede Leistungsbeeinträchtigung kann dann analysiert werden.

Optimierung optimization

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 die Auswirkung erneut testen.

Reporting reporting

Die laufende Berichterstattung wird erforderlich sein, um alle über den Status auf dem Laufenden zu halten. Wie bereits mit Farbcodierung erwähnt, kann die Architekturkarte dafür verwendet werden.

Nachdem alle Tests abgeschlossen sind, können Sie Berichte über folgende Bereiche erstellen:

Leistungsoptimierung bei Verwendung des Dispatchers optimizing-performance-when-using-the-dispatcher

Die Dispatcher ist das Caching- und/oder Lastenausgleichstool der Adobe. Bei Verwendung des Dispatchers sollten Sie Ihre Website hinsichtlich der Cache-Leistung optimieren.

Der Dispatcher bietet eine Reihe integrierter Mechanismen, mit denen Sie die Leistung optimieren können, wenn Ihre Website sie nutzt. In diesem Abschnitt erfahren Sie, wie Sie Ihre Website entwerfen, um die Vorteile der Zwischenspeicherung zu maximieren.

Berechnung des Dispatcher-Cache-Verhältnisses calculating-the-dispatcher-cache-ratio

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 Formel zur Berechnung des Cache-Verhältnisses lautet:

Wenn beispielsweise die Gesamtzahl der Anfragen 129491 und die Anzahl der von der Veröffentlichungsinstanz bereitgestellten Anforderungen 58959 beträgt, beträgt das Cache-Verhältnis: (129491 - 58959)/129491= 54,5%.

Wenn Sie keine 1-zu-1-Publisher/Dispatcher-Paarung haben, müssen Sie Anforderungen von allen Dispatchern und Herausgebern hinzufügen, um eine genaue Messung zu erhalten. Siehe auch Empfohlene Bereitstellungen.

Verwenden einer einheitlichen Seitencodierung using-consistent-page-encoding

Mit der Dispatcher-Version 4.1.11 können Sie Antwortheader zwischenspeichern. Wenn Sie keine Antwort-Header im Dispatcher cachen, können Probleme auftreten, wenn Sie in der Kopfzeile Seitenkodierungsinformationen speichern. In diesem Fall wird die Standardkodierung des Webservers für die Seite verwendet, wenn der Dispatcher eine Seite aus dem Cache bereitstellt. Es gibt zwei Möglichkeiten, dieses Problem zu vermeiden:

        <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

Vermeiden von URL-Parametern avoid-url-parameters

Vermeiden Sie nach Möglichkeit URL-Parameter für Seiten, die Sie zwischenspeichern möchten. Wenn Sie beispielsweise über eine Bildergalerie verfügen, wird die folgende URL nie zwischengespeichert (es sei denn, der Dispatcher ist konfiguriert):

www.myCompany.com/pictures/gallery.html?event=christmas&page=1

Sie können diese Parameter jedoch wie folgt in die Seiten-URL einfügen:

www.myCompany.com/pictures/gallery.christmas.1.html

Anpassen nach URL customize-by-url

Wenn Sie Benutzern erlauben, die Schriftgröße (oder eine andere Layoutanpassung) zu ändern, stellen Sie sicher, dass die verschiedenen Anpassungen in der URL berücksichtigt werden.

Beispielsweise werden Cookies nicht zwischengespeichert. Wenn Sie die Schriftgröße also in einem Cookie (oder einem ähnlichen Mechanismus) speichern, bleibt die Schriftgröße für die zwischengespeicherte Seite nicht erhalten. Daher gibt der Dispatcher Dokumente jeder Schriftgröße zufällig zurück.

Durch Einbeziehung der Schriftgröße in die URL als Selektor wird dieses Problem vermieden:

www.myCompany.com/news/main.large.html

Invalidierung von als Titel verwendeten Bilddateien invalidating-image-files-used-as-titles

Wenn Sie Seitentitel oder anderen Text als Bilder rendern, wird empfohlen, die Dateien so zu speichern, dass sie bei einer Inhaltsaktualisierung auf der Seite gelöscht werden:

Sie können beispielsweise den Titel der Seite myPage.html in der Datei speichern myPage.title.gif. Diese Datei wird automatisch gelöscht, wenn die Seite aktualisiert wird, sodass jede Änderung am Seitentitel automatisch im Cache angezeigt wird.

Invalidierung von Bilddateien für die Navigation invalidating-image-files-used-for-navigation

Wenn Sie Bilder für die Navigationseinträge verwenden, ist die Methode im Wesentlichen die gleiche wie bei Titeln, nur etwas komplexer. Speichern Sie alle Navigationsbilder mit den Zielseiten. Wenn Sie zwei Bilder für normal und aktiv verwenden, können Sie die folgenden Skripte verwenden:

Es ist wichtig, dass Sie diese Bilder mit demselben Namensschild wie die Seite erstellen, um sicherzustellen, dass durch eine Inhaltsaktualisierung diese Bilder sowie die Seite gelöscht werden.

Bei Seiten, die nicht geändert werden, bleiben die Bilder im Cache, obwohl die Seiten selbst normalerweise automatisch invalidiert werden.

Personalisierung personalization

Es wird empfohlen, die Personalisierung auf den erforderlichen Bereich zu beschränken. Um zu veranschaulichen, warum:

Wenn Sie jede Seite personalisieren (zum Beispiel durch Einfügen des Benutzernamens in der Titelleiste), kann dies die Leistung beeinträchtigen.

In Bezug auf das Mischen von eingeschränkten und öffentlichen Inhalten auf einer Seite sollten Sie eine Strategie in Betracht ziehen, die Server-seitige Einfügungen im Dispatcher nutzt, oder Client-seitige Einfügungen über Ajax im Browser.

Sticky-Verbindungen sticky-connections

Sticky-Verbindungen stellen sicher, dass die Dokumente für einen Benutzer alle auf demselben Server erstellt werden. Wenn ein Benutzer diesen Ordner verlässt und später zu ihm zurückkehrt, bleibt die Verbindung erhalten. Definieren Sie einen Ordner für alle Dokumente, die Sticky-Verbindungen für die Website erfordern. Versuchen Sie, keine anderen Dokumente darin zu haben. Dies wirkt sich auf den Lastenausgleich aus, wenn Sie personalisierte Seiten und Sitzungsdaten verwenden.

MIME-Typen mime-types

Es gibt zwei Möglichkeiten, wie ein Browser den Dateityp bestimmen kann:

Für die meisten Dateien wird der MIME-Typ durch die Dateierweiterung angegeben d. h.:

Wenn der Dateiname keine Erweiterung aufweist, wird er als Nur-Text angezeigt.

Mit der Dispatcher-Version 4.1.11 können Sie Antwortheader zwischenspeichern. Wenn Sie die Antwortheader nicht im Dispatcher zwischenspeichern, beachten Sie, dass der MIME-Typ Teil des HTTP-Headers ist. Wenn Ihre AEM-Anwendung Dateien zurückgibt, deren Dateiendung nicht erkannt wird, sondern bei denen der MIME-Typ verwendet wird, werden diese Dateien möglicherweise nicht korrekt angezeigt.

Um sicherzustellen, dass Dateien ordnungsgemäß zwischengespeichert werden, befolgen Sie die folgenden Richtlinien:

Leistung bei der Sicherung backup-performance

In diesem Abschnitt werden mehrere Benchmarks vorgestellt, mit denen die Leistung von AEM-Sicherungen und die Auswirkungen der Sicherungsaktivität auf die Anwendungsleistung bewertet wird. Ein AEM Backup stellt während der Ausführung eine erhebliche Belastung des Systems dar, und wir messen dies sowie die Auswirkungen der Backup-Verzögerungseinstellungen, die versuchen, diese Effekte zu modulieren. Ziel ist es, einige Referenzdaten über die erwartete Leistung von Backups in realistischen Konfigurationen und Mengen von Produktionsdaten bereitzustellen und Anleitungen zur Schätzung der Sicherungszeiten für geplante Systeme bereitzustellen.

Referenzumgebung reference-environment

Physikalisches System physical-system

Die in diesem Dokument berichteten Ergebnisse stammen aus Benchmarks, die in einer Referenzumgebung mit der folgenden Konfiguration ausgeführt wurden. Diese Konfiguration ähnelt einer typischen Produktionsumgebung in einem Rechenzentrum:

Das Festplatten-Subsystem auf diesem Server ist ziemlich schnell und repräsentativ für eine Hochleistungs-RAID-Konfiguration, die möglicherweise auf einem Produktionsserver verwendet wird. Die Backup-Leistung kann abhängig von der Festplattenleistung sein, und die Ergebnisse in dieser Umgebung spiegeln die Leistung bei einer sehr schnellen RAID-Konfiguration wider. Das VMWare-Bild ist so konfiguriert, dass es über ein einzelnes großes Festplattenvolumen verfügt, das sich physisch im lokalen Festplattenspeicher auf dem RAID-Array befindet.

Durch die AEM-Konfiguration werden das Repository und der Datenspeicher auf denselben logischen Datenträger wie das Betriebssystem und die AEM-Software platziert. Das Zielverzeichnis für Backups befindet sich ebenfalls in diesem logischen Dateisystem.

Datenvolumen data-volumes

Die folgende Tabelle zeigt die Größe der Datenvolumen, die in den Backup-Benchmarks verwendet werden. Zunächst wird der anfängliche Grundlinieninhalt installiert, dann werden zusätzliche bekannte Datenmengen hinzugefügt, um die Größe des gesicherten Inhalts zu erhöhen. Sicherungen werden in bestimmten Schritten erstellt, um einen starken Inhaltszuwachs und eine tägliche Erstellung zu gewährleisten. Die Verteilung von Inhalten (Seiten, Bilder, Tags) basiert in etwa auf einer realistischen Produktions-Asset-Komposition. 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 mit einer Größe von 37 kB bis 594 kB hochgeladen.

Das Sicherungs-Benchmark wird mit den zusätzlichen Inhalten, die bei jeder Iteration hinzugefügt werden, wiederholt.

Benchmarkszenarios benchmark-scenarios

Die Sicherungs-Benchmarks decken zwei Hauptszenarien ab: Sicherungen, wenn das System stark ausgelastet ist, und Sicherungen, wenn das System inaktiv ist. Obwohl allgemein empfohlen wird, Sicherungen möglichst bei inaktivem AEM-System durchzuführen, gibt es Situationen, in denen die Sicherung bei laufendem Betrieb durchgeführt werden muss.

Die Sicherungszeiten und die Größe der resultierenden Sicherung können den AEM-Serverprotokollen entnommen werden. Es wird empfohlen, Sicherungen zu Zeiten zu planen, wenn AEM inaktiv ist, z. B. in der Nacht. Dieses Szenario ist für den empfohlenen Ansatz repräsentativ.

Die Last besteht aus Seitenerstellungs-/Löschvorgänge, Durchläufen und Abfragen, wobei der Großteil der Last aus Seitendurchläufen und -abfragen stammt. Durch das Hinzufügen und Entfernen zu vieler Seiten wird die Arbeitsbereichsgröße kontinuierlich erhöht und das Abschließen von Sicherungen verhindert. Die Verteilung der Ladevorgänge, die das Skript verwenden wird, beträgt 75 % Seitendurchläufe, 24 % Abfragen und 1 % Seitenerstellungen (einzelne 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 Auswirkungen der Sicherung auf den Anwendungsdurchsatz werden ermittelt, indem der Szenario-Durchsatz in Transaktionen pro Stunde mit und ohne gleichzeitige Sicherung verglichen wird und Backups mit unterschiedlichen Einstellungen für "Backup Delay" ausgeführt werden.

Zusammenfassung der Ergebnisse summary-of-results

Sicherungsdauer und Durchsatz backup-time-and-throughput

Als Hauptergebnis dieser Benchmarks kann gezeigt werden, wie die Sicherungsdauer je nach Sicherungstyp und Datenmenge variiert. Die folgende Grafik zeigt die Sicherungsdauer, die mit der standardmäßigen Sicherungskonfiguration abgerufen wurde, in Abhängigkeit von der Gesamtzahl der Seiten.

Die Sicherungszeiten in einer inaktiven Instanz sind relativ konsistent und erreichen im Durchschnitt 0,608 MB/s unabhängig von vollständigen oder inkrementellen Backups (siehe Abbildung unten). Die Sicherungsdauer ist lediglich eine Funktion der Datenmenge, die gesichert wird. Die Zeit für den Abschluss einer vollständigen Sicherung steigt deutlich mit der Gesamtzahl der Seiten. Die Zeit, um eine inkrementelle Sicherung durchzuführen, steigt ebenfalls mit der Gesamtanzahl der Seiten, jedoch mit einer wesentlich geringeren Geschwindigkeit. Die Dauer der inkrementellen Sicherung ist aufgrund der relativ geringen Menge an zu sichernden Daten viel kürzer.

Die Größe der erzeugten Sicherung ist entscheidend für die Sicherungsdauer. Die folgende Grafik zeigt die benötigte Zeit in Abhängigkeit von der endgültigen Backup-Größe.

Diese Grafik zeigt, dass sowohl inkrementelle als auch vollständige Sicherungen einem einfachen Größe- bzw. Zeitmuster entsprechen, das wir als Durchsatz messen können. Die Sicherungszeiten in einer inaktiven Instanz sind relativ konsistent und erreichen im Durchschnitt 0,61 MB/s, unabhängig von vollständigen oder inkrementellen Backups in der Benchmark-Umgebung.

Sicherungsverzögerung backup-delay

Der Parameter für die Sicherungsverzögerung wird bereitgestellt, um zu begrenzen, in welchem Umfang Backups zu Problemen bei Produktions-Workloads führen können. Der Parameter gibt eine Wartezeit in Millisekunden an, die in den Sicherungsvorgang Datei für Datei integriert wird. Der Gesamteffekt hängt zum Teil von der Größe der betroffenen Dateien ab. Die Messung der Backup-Leistung in MB/s bietet eine vernünftige Möglichkeit, die Auswirkungen einer Verzögerung auf das Backup zu vergleichen.

Zum Vergleich des Durchsatzes, der mithilfe einer Dateisystemsicherung (mithilfe von "tar") zur Sicherung derselben Repository-Dateien ermittelt wurde. Die Leistung des Tars ist vergleichbar, aber etwas höher als die Sicherung mit einer Verzögerung von null. Durch die Festlegung einer geringen Verzögerung wird der Backup-Durchsatz erheblich reduziert, und die Standardverzögerung von 10 ms führt zu einem deutlich geringeren Durchsatz. In Situationen, in denen Sicherungen geplant werden können, wenn die Gesamtnutzung der Anwendung sehr gering ist oder die Anwendung vollständig inaktiv sein kann, ist es wahrscheinlich wünschenswert, die Verzögerung unter den Standardwert zu reduzieren, damit die Sicherung schneller fortgesetzt werden kann.

Die tatsächlichen Auswirkungen des Durchsatzes einer laufenden Sicherung hängen von der Anwendungs- und Infrastrukturdetails ab. Die Auswahl des Verzögerungswerts sollte durch empirische Analyse der Anwendung erfolgen, sollte jedoch so klein wie möglich sein, damit Backups so schnell wie möglich abgeschlossen werden können. Da es nur eine schwache Korrelation zwischen der Auswahl des Verzögerungswerts und den Auswirkungen auf den Anwendungsdurchsatz gibt, sollte die Wahl der Verzögerung kürzere Backup-Zeiten bevorzugen, um die Gesamtauswirkungen von Backups zu minimieren. Eine Sicherung, die 8 Stunden dauert, aber den Durchsatz um -20 % beeinflusst, hat wahrscheinlich eine größere Gesamtwirkung als eine Sicherung, die 2 Stunden dauert, aber den Durchsatz um -30 % beeinflusst.

Verweise references