Sie sehen sich Hilfeinhalte der folgenden Version an:

Hinweis:

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.

Zusätzlich ist ein Artikel in der Wissensdatenbank mit Tipps zur Leistungsoptimierung verfügbar.

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. In dieser Umgebung ist die Anzahl der Anforderungen höher, während die Geschwindigkeit genauso wichtig ist. Doch da die Anforderungen weniger dynamisch sind, können Methoden zur zusätzlichen Leistungssteigerung angewendet werden. Hierzu zählen das Zwischenspeichern des Inhalts und die Lastverteilung.

Hinweis:

 

Methode zur Leistungsoptimierung

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

  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 für Webprojekte im Allgemeinen. Projektleiter und Systemadministratoren können damit gewährleisten, dass bei ihren Projekten keine Leistungsprobleme auftreten.

Zeit für die Optimierung einplanen

chlimage_1

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 probeweise für eine begrenzte Zielgruppe gestartet werden, um unmittelbare Erfahrungen zu sammeln und weitere Optimierungen vorzunehmen. Dadurch wird zusätzlicher Druck vermieden, der mit einem vollständigen Launch einhergeht.

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

chlimage_1

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 „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

chlimage_1

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.

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

chlimage_1

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

chlimage_1

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.

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 sollte innerhalb von 500 ms bis 1.000 ms beantwortet werden.
  • Keine Seitenanforderung sollte länger als 1 Sekunde dauern.

Bei den obigen Zahlen gelten die folgenden Bedingungen:

  • Gemessen in der Veröffentlichungsumgebung (keine zusätzliche Last durch die Autorenumgebung)
  • Gemessen auf dem Server (keine zusätzliche Last durch das Netzwerk)
  • Nicht gecacht (kein CQ-Ausgabe-Cache, kein Dispatcher-Cache)
  • Nur für komplexe Objekte mit vielen Abhängigkeiten (HTML, JS, PDF usw.)
  • Keine andere Last auf dem System

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

  • Ineffiziente Speicherung im Dispatcher-Cache
  • 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:

  • das Abfrageprotokoll request.log;
  • komponentenbasiertes Timing;
  • 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 ermöglichen eine flüssigere Codeumsetzung
  • 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:
chlimage_1
  • Der Zeitraum, in dem Bearbeitungen durchgeführt werden (normalerweise während der Büroöffnungszeiten, länger bei internationalen Vorgängen).
  • Die durchschnittliche Größe der hochgeladenen Bilder (und die Größe der pro Bild generierten Darstellungen) in Megabyte.
  • Bestimmen Sie die durchschnittliche Datenrate:
chlimage_1
  • 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 CQ-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 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 veranschaulicht den möglichen Pfad einer CQ-Inhaltsanforderung – und damit die Anzahl der unterschiedlichen Elemente, die die Leistung beeinträchtigen können.

chlimage_1

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

Volumen

Die Menge der vom System verarbeiteten und bereitgestellten Ausgabedaten

Kapazität

Die Fähigkeit des Systems, ein gewisses Volumen bereitzustellen

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

chlimage_1

Es gibt einige Funktionsbereiche, die häufig für eine Leistungsminderung verantwortlich sind:

  • Zwischenspeicherung
  • 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.

Hinweis:

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.

Konfiguration zur Leistungsoptimierung

Gewisse Aspekte von CQ (und/oder des zugrunde liegenden CRX) 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.

Hinweis:

Weitere Informationen finden Sie im Artikel in der Wissensdatenbank.

Suchindizierung

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

Hier finden Sie die aktuellen Indizierungsinformationen:

Gleichzeitige Workflow-Verarbeitung

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 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 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 in der Apache Sling Job Queue Configuration Service Factory zur Verarbeitung von Workflow-Aufgaben erstellt:

  • Granite Workflow Queue: Für die meisten Workflow-Schritte, wie diejenigen zur Verarbeitung von DAM-Assets, wird der Granite Workflow Queue-Dienst verwendet.
  • Granite Workflow External Process Job Queue: Dieser Dienst wird für spezielle externe Workflow-Schritte verwendet, die in der Regel zur Kontaktierung eines externen Systems und zur Abfrage von Ergebnissen dienen.  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. 

Hinweis: Die Konfiguration dieser Auftragswarteschlangen hat Auswirkungen auf alle Workflows, es sei denn, Sie haben eine Auftragswarteschlange für ein bestimmtes Workflow-Modell erstellt (siehe Warteschlange für ein bestimmtes Workflow-Modell konfigurieren weiter unten).

Konfiguration im Repository 

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.

Konfigurieren Sie die Eigenschaft „queue.maxparallel“.

Konfiguration in der Web-Konsole

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 „Maximum Parallel Jobs“.

Warteschlange für ein bestimmtes Workflow-Modell 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*

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

  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 ein Bild zu Assets hinzu, um den Workflow „DAM-Update-Asset“ auszuführen. 

  2. Öffnen Sie die Sling Jobs-Konsole. (http://localhost:4502/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 Werkskonfigurationen sind ähnlich der Granite Workflow Queue, die in Gleichzeitige Workflow-Verarbeitung beschrieben wird, mit der Ausnahme, dass die Themen-Eigenschaft mit dem Thema Ihrer Workflow-Aufträge übereinstimmt.

CQ5 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:

  • Aufgrund regelmäßiger Uploads zahlreicher Assets in die Autorenumgebung entsteht eine hohe Last. In dieser Situation kann eine separate DAM-Instanz speziell für die Inhaltsverarbeitung reserviert werden.
  • Sie haben mehrere Teams an Standorten auf der ganzen Welt (z. B. USA, Europa und Asien).

Zusätzliche Erwägungen sind:

  • Trennung von unfertiger Arbeit in der Autorenumgebung von abgeschlossener Arbeit in der Veröffentlichungsumgebung
  • Trennung von internen Benutzern in der Autorenumgebung von externen Besuchern/Benutzern in der Veröffentlichungsumgebung (z. B. Agenten, Pressevertreter, Kunden, Auszubildende 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 Überblick über Probleme bei der Definition eines Testkonzepts speziell für Leistungstests in der Veröffentlichungsumgebung. Dies ist vor allem für QA-Beauftragte, Projektleiter und Systemadministratoren von Interesse.

Im Folgenden wird die übliche Vorgehensweise bei der Durchführung von Leistungstests bei einer CQ-Anwendung in der Veröffentlichungsumgebung beschrieben. 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.

Überprüfung des Wissens

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

  • Die Architektur Ihrer Testumgebung
  • Ein Plan der Anwendung mit einer genauen Angabe der internen Elemente, die getestet werden müssen (sowohl einzeln als auch in Kombination)

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:

  • Die wichtigsten Anwendungsfälle für Ihr Unternehmen
  • Die wichtigsten technischen Anwendungsfä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 Anzahl Benutzer Tx/Sek (erwartet) Tx/Sek (getestet) Beschreibung 
Homepage, einzelner Benutzer Durchschnitt 1 1    
  Spitze 1 3    
Homepage, 100 Benutzer Durchschnitt 100 3    
  Spitze 100 3  

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 Anzahl Benutzer Tx/Sek (erwartet) Tx/Sek (getestet) Beschreibung 
Mischung Durchschnitt Homepage 10 1    
  Suche 10 1    
  Neuigkeiten 10 2    
  Ereignisse 10 1    
  Aktivierungen 10 3   Simulation von Autorenverhalten
Mischung Spitzen Homepage 100 5    
  Suche 50 5    
  Neuigkeiten 100 10    
  Ereignisse 100 10    
  Aktivierungen 20 20   Simulation von Autorenverhalten

„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 Anzahl Benutzer Tx/Sek (erwartet) Tx/Sek (getestet) Beschreibung 
„Going Live“-Spitze Homepage 200 20    
  Suche 100 10    
  Neuigkeiten 200 20    
  Ereignisse 200 20    
  Aktivierungen 20 20   Simulation von Autorenverhalten

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 ein Benutzer einen ungültigen Begriff in das Suchfeld eingibt?
  • Was passiert, wenn der Suchbegriff so allgemein ist, dass eine übermäßig große Anzahl an Ergebnissen zurückgegeben wird?

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 Anzahl Benutzer Tx/Sek (erwartet) Tx/Sek (getestet) Beschreibung 
Überlastung der Suchkomponente Suche mit Platzhalterzeichen (Sternchen) 10 1   Nur *** werden gesucht.
  Stopp-Wort 20 2   Suche nach einem Stopp-Wort
  Leerer String 10 1   Suche nach einem leeren String
  Sonderzeichen 10 1   Suche 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 Anzahl Benutzer Tx/Sek (erwartet) Tx/Sek (getestet) Beschreibung 
Belastungstest (72 Stunden) Homepage 10 1    
  Suche 10 1    
  Neuigkeiten 20 2    
  Ereignisse 10 1    
  Aktivierungen 1 3   Simulation von Autorenverhalten

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:

  • Sie dürfen die Funktionalität nicht beeinträchtigen.
  • Sie wurden vor ihrer Veröffentlichung Belastungstests unterzogen.

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.

Berichterstellung

Um alle Beteiligten über den jeweiligen Stand auf dem Laufenden zu halten, ist eine kontinuierliche Berichterstellung erforderlich. Wie bereits gesagt, kann hierfür ein Anwendungsdiagramm mit Farbkodierung verwendet werden.

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

  • Alle festgestellten kritischen Fehler
  • Nicht kritische Probleme, die noch weiter untersucht werden müssen
  • Etwaige Annahmen während der Tests
  • Etwaige Empfehlungen, die sich aus den Tests 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.

Hinweis:

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.

Hinweis:

Beachten Sie dabei, dass der Dispatcher den Cache auf einem Standardwebserver speichert. Dies bedeutet, dass Sie:

  • alle Daten zwischenspeichern können, die als Seite gespeichert und mit einer URL abgerufen werden können
  • keine anderen Daten speichern können, z. B. Cookies, Sitzungsdaten und Formulardaten

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-Header cachen; siehe Cachen von HTTP-Antwort-Headern.

 

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

  • (Die Gesamtzahl der Anforderungen minus der Anzahl der Anforderungen in der Veröffentlichungsumgebung) 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.

Hinweis:

Für eine optimale Leistung empfiehlt Adobe ein Cache-Verhältnis von 90 % bis 95 %.

Verwenden einer einheitlichen Seitenkodierung

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 Kodierung 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&amp;page=1
Sie können diese Parameter allerdings in der URL der Seite platzieren:
www.myCompany.com/pictures/gallery.christmas.1.html

Hinweis:

Diese URL ruft dieselbe Seite und Vorlage auf wie „gallery.html“. In der Vorlagendefinition können Sie angeben, welches Skript die Seite rendern soll, oder Sie können ein Skript für alle Seiten verwenden.

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

Hinweis:

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.

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 für die Bilddatei das folgende Format für die Seitenbenennung:

    <Name der Seitendatei>.<Name der Bilddatei>

Beispielsweise können Sie den Titel der Seite „myPage.html“ in der Datei „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.

Hinweis:

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.

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

Der Dispatcher kann keine personalisierten Daten zwischenspeichern. Sie sollten die Personalisierung daher nur bei Bedarf verwenden. 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.

Hinweis:

Wenn Sie jede Seite personalisieren (zum Beispiel durch Einfügen des Benutzernamens in der Titelleiste), können Sie sie nicht zwischenspeichern. Dies kann die Leistung erheblich beeinträchtigen.

Wenn dies jedoch erforderlich ist, haben Sie folgende Möglichkeiten:

 

  • Sie können die Seite mit iFrames aufteilen in einen Teil, der für alle Benutzer gleich ist, und einen Teil, der bei allen Seiten eines Benutzers gleich ist. Diese beiden Teile können dann zwischengespeichert werden.
  • Sie können mit clientseitigem JavaScript personalisierte Informationen anzeigen. Sie müssen jedoch sicherstellen, dass die Seite weiterhin richtig angezeigt wird, wenn ein Benutzer JavaScript deaktiviert.

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 die Erweiterung (z. B. .html, .gif, .jpg)
  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 die Erweiterung (z. B. .html, .gif, .jpg)
  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 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 richtig zwischengespeichert werden, halten Sie sich an die folgenden Richtlinien.

  • Stellen Sie sicher, dass Dateien immer die richtige Erweiterung aufweisen.
  • Verwenden Sie möglichst keine allgemeinen Dateibereitstellungsskripts mit URLs wie „download.jsp?file=2214“. Schreiben Sie das Skript so um, dass die URLs die Dateispezifikation enthalten. Im obigen Beispiel wäre dies „download.2214.pdf“.

Leistung bei der Sicherung

In diesem Abschnitt werden mehrere Benchmarks vorgestellt, mit denen die Leistung von CQ-Sicherungen und die Auswirkungen der Sicherungsaktivität auf die Anwendungsleistung bewertet wird. Die CQ-Sicherung stellt eine beträchtliche Belastung des laufenden Betriebs dar. Wir messen diese Belastung ebenso wie die Auswirkungen der Sicherungsverzögerungseinstellungen, mit denen versucht wird, diese Auswirkungen abzufedern. 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 Produktionsumgebung 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 mit CQ 5.5 GM.

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.

Durch die CQ-Konfiguration werden das Repository und der Datenspeicher auf denselben logischen Datenträger wie das Betriebssystem und die CQ-Software platziert. 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
Ursprüngliche Installation 69,610 562 256 237
Kleine Inhaltsmenge für inkrementelle Sicherung
+100 +2 +2
Große Inhaltsmenge für vollständige Sicherung
+10,000 +100 +100

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

Benchmark-Szenarien

Die Sicherungs-Benchmarks beziehen sich auf zwei Hauptszenarien: Sicherungen bei hoher Anwendungslast und Sicherungen bei inaktivem System.  Obwohl allgemein empfohlen wird, Sicherungen möglichst bei inaktivem CQ-System durchzuführen, gibt es Situationen, in denen die Sicherung bei laufendem Betrieb durchgeführt werden muss. 

Ruhezustand:

Sicherungen werden durchgeführt, wenn keine andere Aktivität auf CQ vorhanden ist.

Unter Last:

Sicherungen werden durchgeführt, wenn das System zu 80 % mit Online-Prozessen ausgelastet ist. Die Sicherungsverzögerung variiert, um die Auswirkung auf die Last zu ermitteln.

Die Sicherungszeiten und die Größe der resultierenden Sicherung können den CQ-Serverprotokollen entnommen werden. Es wird empfohlen, Sicherungen zu Zeiten zu planen, wenn CQ inaktiv ist, z. B. 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.

Verzögerungseinstellung

Bei mehreren Szenarien haben wir auch unterschiedliche Sicherungsverzögerungseinstellungen verwendet (10 ms (Standard), 1 ms und 0 ms), um zu testen, wie diese Einstellungen die Sicherungsleistung beeinflussen.

Sicherungstyp

Bei allen Sicherungen hat es sich um externe Sicherungen des Repositorys in ein Sicherungsverzeichnis ohne Komprimierung gehandelt, außer in einem Fall, bei dem zu Vergleichszwecken der tar-Befehl direkt angewendet 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

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

chlimage_1

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.

chlimage_1

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.
  • Diese Auswirkung kann nur geringfügig sein (5 % Durchsatzverminderung) oder sehr groß (75 %) Dies hängt zum Großteil von der jeweiligen 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.
chlimage_1

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

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie