Leistungsoptimierung

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:

Autorenumgebung

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.

Veröffentlichungsumgebung

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.

Methode zur Leistungsoptimierung

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:

1. Zeit für die Optimierung einplanen
2. Reale Situationen simulieren
3. Konkrete Ziele festlegen
4. Relevante Maßnahmen treffen
5. Agile Iterationszyklen

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.

Zeit für die Optimierung einplanen

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.

Reale Situationen simulieren

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.

Konkrete Ziele festlegen

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

Relevante Maßnahmen treffen

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.

Agile Iterationszyklen

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.

Allgemeine Leistungsrichtlinien

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

• 70 % der Seitenanforderungen sollten in weniger als 100 ms beantwortet werden.
• 25 % der Seitenanforderungen sollten innerhalb von 100 ms bis 300 ms beantwortet werden.
• 4 % der Seitenanforderungen sollten innerhalb von 300 ms bis 500 ms beantwortet werden.
• 1 % der Seitenanforderungen sollten innerhalb von 500 ms bis 1000 ms beantwortet werden.
• Keine Seitenanforderung sollte länger als 1 Sekunde dauern.

Bei den obigen Zahlen gelten die folgenden Bedingungen:

• Beim Veröffentlichen gemessen (keine Gemeinkosten im Zusammenhang mit einer Authoring-Umgebung)
• Auf dem Server gemessen (kein Netzwerkaufwand)
• Nicht zwischengespeichert (kein AEM-Ausgabecache, kein Dispatcher-Cache)
• Nur für komplexe Elemente mit vielen Abhängigkeiten (HTML, JS, PDF, …)
• Keine weitere Belastung des Systems

Häufige Ursachen für einen Leistungsabfall sind vor allem:

• Ineffizienz bei Dispatcher-Caching
• Die Verwendung von Abfragen in normalen Anzeigevorlagen.

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:

• Die request.log
• Komponentenbasiertes Timing
• Nicht zuletzt ein Java-Profiler.

Leistung beim Laden und Bearbeiten von digitalen Assets

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:

• CPU - mehrere Kerne sorgen bei der Transkodierung für mehr Effizienz
• Festplatte: parallele RAID-Festplatten bewirken dasselbe

Stellen Sie zur Leistungssteigerung die folgenden Überlegungen an:

• Wie viele Assets werden pro Tag hochgeladen? Eine gute Schätzung erhalten Sie mit folgender Formel:

• Der Zeitraum, in dem Änderungen vorgenommen werden (normalerweise die Dauer des Arbeitstages, mehr für internationale Operationen).
• Die durchschnittliche Größe der hochgeladenen Bilder (und die Größe der pro Bild generierten Darstellungen) in Megabyte.
• Bestimmen Sie die durchschnittliche Datenrate:

• 80 % aller Bearbeitungen werden in 20 % der Zeit durchgeführt, weshalb zu Spitzenzeiten viermal die durchschnittliche Datenrate anfällt. Dies ist Ihr Leistungsziel.

Leistungsüberwachung

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:

• Volumen : 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 einige Funktionsbereiche, die häufig für eine Leistungsminderung verantwortlich sind:

• Caching
• Code der Anwendung (Ihres Projekts)
• Suchfunktion

Grundregeln für die Leistung

Gewisse Regeln sollten bei der Leistungsoptimierung beachtet werden:

• Die Leistungsanpassung muss Teil eines jeden Projekts sein.
• Führen Sie die Optimierung nicht in einer frühen Phase des Entwicklungszyklus durch.
• Die Leistung ist nur so gut wie das schwächste Glied.
• Achten Sie immer auf das Verhältnis zwischen Kapazität und Volumen.
• Optimieren Sie wichtige Dinge zuerst.
• Führen Sie nie Optimierungen ohne realistische Ziele durch.

Konfiguration zur Leistungsoptimierung

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

Ab AEM 6.0 wird eine Oak-basierte Repository-Architektur verwendet.

Hier finden Sie die aktuellen Indizierungsinformationen:

• Best Practices für Abfragen und Indizierung
• Anforderungen und Indizierung

Gleichzeitige Verarbeitung von Workflows

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:

• Granite-Workflow-Warteschlange: Die meisten Arbeitsablaufschritte, z. B. die, die DAM-Assets verarbeiten, verwenden den Granite Workflow Queue-Dienst.
• Externe Prozessauftragswarteschlange für Granite-Workflow: Dieser Dienst wird für spezielle externe Arbeitsablaufschritte verwendet, die normalerweise zur Kontaktaufnahme mit einem externen System und zur Ergebnisabfrage verwendet werden. Beispielsweise wird der Schritt „InDesign Media Extraction Process“ als externer Prozess implementiert. Die Workflow-Engine verwendet die externe Warteschlange zur Verarbeitung der Abfrage. (Siehe com.day.cq.workflow.exec.WorkflowExternalProcess.)

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

Konfiguration im Repository

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.

Konfiguration in der Web-Konsole

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.

Konfigurieren der Warteschlange für einen spezifischen Workflow

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.

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

2. Öffnen Sie die Sling Jobs-Konsole (https://<host>:<port>/system/console/slingevent).

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

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

AEM 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

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

• Sie haben eine hohe Last, da Sie regelmäßig eine große Anzahl von Assets für die Autorendatei hochladen. hier kann eine separate DAM-Instanz dem Servicing-Autor gewidmet werden.
• Sie haben mehrere Teams an weltweiten Standorten (z.B. USA, Europa, Asien).

Zusätzliche Erwägungen sind:

• Trennung von "laufendem Werk"beim Autor und "endgültig"beim Veröffentlichen
• Trennen von internen Besuchern beim Autor von externen Besuchern/Besuchern bei der Veröffentlichung (z.B. Agenten, Pressevertreter, Kunden, Studenten usw.).

Best Practices zur Qualitätssicherung

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:

• Überprüfung des Wissens
• Definition des Umfangs
• Testmethoden
• Definition von Leistungszielen
• Optimierung

Die Kontrolle ist ein zusätzlicher, alles umfassender Prozess, der nötig ist, sich aber nicht auf Tests beschränkt.

Überprüfung des Wissens

Der erste Schritt besteht darin, die grundlegenden für Tests erforderlichen Informationen zu dokumentieren:

• Die Architektur Ihrer Test-Umgebung
• Eine Anwendungszuordnung, in der die internen Elemente aufgeführt sind, die getestet werden müssen (sowohl isoliert als auch kombiniert)

Testarchitektur

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.

Anwendungsdiagramm

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.

Definition des Umfangs

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:

• Wichtigste geschäftliche Verwendungsfälle
• Wichtigste technische Verwendungsfälle

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:

• End-to-end-Antwortzeit
• Servlet-Antwortzeit
• Reaktionszeit für eine einzelne Komponente
• Reaktionszeit für die Dienste
• Anzahl der inaktiven Threads im Thread-Pool
• Anzahl der freien Verbindungen
• Systemressourcen wie CPU und I/O-Zugriff

Testmethoden

Im Folgenden werden vier Szenarien für das Definieren und Testen der Leistungsziele beschrieben:

• Tests einzelner Komponenten
• Tests kombinierter Komponenten
• Going Live-Szenario
• Fehlerszenarien

Es gelten die folgenden Prinzipien:

Belastungsgrenze der Komponente

• Jede Komponente hat eine bestimmte Belastungsgrenze in Bezug auf die Leistung. Dies bedeutet, dass eine Komponente bis zu einem gewissen Punkt eine gute Leistung erbringt, diese ab diesem Punkt aber rapide nachlässt.
• Um einen vollständigen Überblick über die Anwendung zu erhalten, müssen Sie zunächst feststellen, wann bei Ihren Komponenten diese Belastungsgrenze erreicht ist.
• Um die Belastungsgrenze festzustellen, können Sie einen Belastungstest durchführen, bei dem Sie über einen gewissen Zeitraum die Anzahl der Benutzer erhöhen und so die Last steigern. Durch die Überwachung dieser Last und der Antwort der Komponenten erkennen Sie ein spezifisches Leistungsverhalten, wenn die Belastungsgrenze der Komponente erreicht ist. Diese Grenze kann durch die Anzahl gleichzeitiger Transaktionen pro Sekunde zusammen mit der Anzahl gleichzeitiger Benutzer angegeben werden (sofern die Komponente von diesem KPI beeinflusst wird).
• Diese Information kann dann als Vergleichswert für Verbesserungen herangezogen werden und Ihnen helfen, die Effizienz der ergriffenen Maßnahmen zu beurteilen und Testszenarien zu definieren.

Transaktionen

• Der Ausdruck „Transaktion“ bezieht sich auf die Anforderung einer kompletten Webseite, einschließlich der Seite selbst und aller darauf folgenden Aufrufe, d. h. auf die Seitenanforderung, etwaige AJAX-Aufrufe, Bilder und andere Objekte.Anforderungsanalyse
• Um jede Anforderung vollständig zu analysieren, können Sie jedes Element des Aufrufstapels abbilden und dann aus der durchschnittlichen Verarbeitungszeit eines jeden Elements die Summe berechnen.

Leistungsziele definieren

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.

Tests einzelner Komponenten

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

Tests kombinierter Komponenten

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.

„Going Live“-Tests

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.

Tests von Fehlerszenarien

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:

• Was passiert, wenn der Benutzer versucht, einen ungültigen Suchbegriff in das Suchfeld einzugeben?
• Was passiert, wenn der Suchbegriff so allgemein ist, dass er eine übermäßige Anzahl an Ergebnissen zurückgibt

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

Belastungstests

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.

Optimierung

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:

• Die Funktion wird nicht beeinträchtigt
• mit den Belastungstests vor Freigabe überprüft wurde,

Für die Lastgenerierung, Leistungsüberwachung und/oder Ergebnisanalyse steht eine Reihe von Tools zur Verfügung:

• JMeter
• Load Runner
• Determyne InsideApps
• InfraRED
• Java Interactive Profile
• Viele weitere…

Nach der Optimierung müssen Sie einen erneuten Test durchführen, um die Auswirkungen zu überprüfen.

Berichterstellung

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:

• Alle kritischen Fehler gefunden
• Nicht kritische Fragen, die noch einer weiteren Untersuchung bedürfen
• Annahmen während der Prüfung
• Empfehlungen, die sich aus dem Test ergeben

Optimieren der Leistung durch den Einsatz des Dispatchers

Der Dispatcher ist das Caching- und/oder Lastausgleichs-Tool von Adobe. Bei Verwendung des Dispatchers sollten Sie Ihre Website hinsichtlich der Cache-Leistung optimieren.

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.

Dispatcher-Cache-Verhältnis berechnen

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:

• (Die Gesamtanzahl der Anforderungen minus die Anzahl der Anforderungen bei der Veröffentlichung) dividiert durch die Gesamtanzahl der Anforderungen.

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.

Verwenden einer einheitlichen Seitencodierung

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:

• Wenn Sie nur eine Kodierung verwenden, achten Sie darauf, dass die auf dem Webserver verwendete Kodierung der Standardkodierung der AEM-Website entspricht.
• Verwenden Sie ein <META>-Tag im HTML-Abschnitt head, um die Codierung festzulegen. Beispiel:

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

Vermeiden von URL-Parametern

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

Anpassen nach URL

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

Invalidierung von als Titel verwendeten Bilddateien

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:

1. Platzieren Sie die Bilddatei im selben Verzeichnis wie die Seite.

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

Invalidierung von Bilddateien für die Navigation

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:

• Ein Skript, das die Seite normal anzeigt.
• Ein Skript, das „.normal“-Anforderungen verarbeitet und das normale Bild zurückgibt.
• Ein Skript, das „.active“ verarbeitet und das aktivierte Bild zurückgibt.

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.

Personalisierung

Es wird empfohlen, die Personalisierung auf den erforderlichen Bereich zu beschränken. Dies hat folgende Gründe:

• Wenn Sie eine frei anpassbare Startseite verwenden, muss diese Seite jedes Mal erstellt werden, wenn ein Benutzer sie anfordert.
• Wenn Sie stattdessen eine Auswahl von 10 verschiedenen Startseiten anbieten, können Sie diese zwischenspeichern und so die Leistung verbessern.

Wenn Sie jede Seite personalisieren (z. B. indem Sie den Namen des Benutzers in die Titelleiste setzen), kann dies Auswirkungen auf die Leistung haben.

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.

Sticky-Verbindungen

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.

MIME-Typen

Es gibt zwei Möglichkeiten, wie ein Browser den Typ einer Datei bestimmen kann:

1. Durch seine Erweiterung (z. .html, .gif, .jpg usw.)
2. Durch den MIME-Typ, den der Server mit der Datei sendet.

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

1. Durch seine Erweiterung (z. .html, .gif, .jpg usw.)
2. Durch den MIME-Typ, den der Server mit der Datei sendet.

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.

• Stellen Sie sicher, dass Dateien immer die richtige Erweiterung aufweisen.
• Vermeiden Sie generische Dateibereitstellungsskripte, die URLs wie 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.

Leistung bei der Sicherung

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.

Referenzumgebung

Physisches System

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:

• H-P ProLiant DL380 G6, 8 CPUs x 2.533 GHz
• Seriell angeschlossene SCSI-Laufwerke mit 300 GB, 10.000 RPM
• Hardware-RAID-Controller; 8 Festplatten in einer „RAID 0+5“-Anordnung
• VMware-Image-CPU x 2 Intel Xeon E5540 @ 2,53 GHz
• RedHat Linux 2.6.18-194.el5; Java 1.6.0_29
• Einzelne Autoreninstanz

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.

Datenmengen

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.

Benchmark-Szenarien

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.

• Leerlauf : Sicherungen werden ohne weitere Aktivität auf AEM ausgeführt.
• Unter Laden - Backups werden ausgeführt, während das System zu 80 % aus Online-Prozessen geladen wird. Die Sicherungsverzögerung variiert, um die Auswirkung auf die Last zu ermitteln.

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.

• Einstellung der Verzögerung - In einigen Szenarien haben wir auch die Einstellung für die Backup-Verzögerung geändert, wobei Werte von 10 ms (Standard), 1 ms und 0 ms verwendet wurden, um zu untersuchen, wie diese Einstellung die Leistung von Backups beeinflusste.
• Sicherungsart : Alle Sicherungen waren externe Sicherungen des Repositorys, die ohne Erstellung einer ZIP-Datei in einem Backup-Verzeichnis erstellt wurden, außer in einem Fall, in dem der Befehl "tar"direkt verwendet wurde. Da inkrementelle Sicherungen nicht in eine ZIP-Datei geschrieben werden können oder wenn die vorherige vollständige Sicherung eine ZIP-Datei ist, wird in Produktionssituationen meist die Sicherungsverzeichnismethode verwendet.

Zusammenfassung der Ergebnisse

Backup-Zeit und -Durchsatz

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.

Sicherungsverzögerung

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.

• Die gleichzeitige Durchführung einer Sicherung während der regulären Anwendung wirkt sich negativ auf den Durchsatz der normalen Last aus.
• Der Einfluss kann gering sein (bis zu 5 %) oder sehr bedeutsam sein, was bis zu 75 % zu einem Rückgang des Durchsatzes führt, und das hängt wahrscheinlich mehr als alles andere von der Anwendung ab.
• Die Sicherung stellt keine große Last für die CPU dar. Prozessorintensive Produktionsaufgaben werden deshalb durch die Sicherung weniger stark beeinträchtigt als I/O-intensive Aufgaben.

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.

Verweise

• Administration – Sichern und Wiederherstellen
• Verwaltung – Kapazität und Volumen