Festlegen von Zielen
Bevor Sie mit Leistungstests beginnen, müssen Sie nicht funktionale Anforderungen festlegen, um die Lade- und Antwortzeiten anzugeben. Wenn Sie von einem vorhandenen System migrieren, stellen Sie sicher, dass die Antwortzeiten Ihren aktuellen Produktionswerten ähnlich sind. Für die Auslastung ist es am besten, die aktuelle Spitzenlast zu verdoppeln. Dadurch wird sichergestellt, dass die Website auch weiterhin gut funktionieren kann, wenn sie wächst.
Tools
Auf dem Markt ist eine Vielzahl von Tools für Leistungstests erhältlich. Stellen Sie beim Ausführen eines Lastgenerators sicher, dass die Computer, die die Tests durchführen, über ausreichend Netzwerkbrandbreite verfügen. Andernfalls wird keine zusätzliche Belastung in der getesteten Umgebung erzeugt, sobald der Testrechner die Grenzen ihrer Verbindung erreicht.
Test-Tools
-
Das Tool Tough Day von Adobe kann verwendet werden, um Auslastung auf AEM-Instanzen zu erzeugen und Leistungsdaten zu sammeln. Das Entwicklungs-Team von Adobe AEM setzt dieses Tool für Belastungstests beim eigentlichen AEM-Produkt ein. Die in Tough Day ausgeführten Skripte werden über Eigenschaftendateien und JMX-XML-Dateien konfiguriert. Weitere Informationen finden Sie unter der Tough Day-Dokumentation.
-
AEM bietet vorkonfigurierte Tools, um problematische Abfragen, Anforderungen und Fehlermeldungen schnell anzuzeigen. Weitere Informationen finden Sie im Abschnitt Diagnose-Tools der Dokumentation zum Vorgangs-Dashboard.
-
Apache bietet ein Produkt namens JMeter an, das Leistungs- und Belastungstests sowie eine Überprüfung des Funktionsverhaltens ermöglicht. Es handelt sich um eine Open-Source-Software, die kostenlos verwendet werden kann, aber eine kleinere Funktion hat als Unternehmensprodukte und eine stärkere Lernkurve aufweist. JMeter können Sie auf der Apache-Website unter https://jmeter.apache.org/ herunterladen.
-
Website-Belastungstests-Tools wie Vercara können ebenfalls verwendet werden.
-
Beim Testen mobiler oder responsiver Websites muss ein separater Satz von Tools verwendet werden. Diese drosseln die Netzwerkbrandbreite, um langsamere mobile Verbindungen wie 3G oder EDGE zu simulieren. Zu den gängigeren Tools gehören:
- Network Link Conditioner mit einer benutzerfreundlichen Oberfläche und einer relativ niedrigen Ebene im Netzwerk-Stack. Es sind OS X- und iOS-Versionen verfügbar.
- Charles, eine Web-Debugging-Proxy-Anwendung, die u. a. eine Netzwerkdrosselung ermöglicht. Es sind Versionen für Windows, OS X und Linux® verfügbar.
Optimierungs-Tools
Überwachung
Die Dokumentation Überwachung der Leistung liefert zahlreiche Informationen zu Tools und Methoden für die Diagnose von Problemen und Erkennung von Optimierungsbereichen.
Entwicklermodus in der Touch-Benutzeroberfläche
Eine der neuen Funktionen der Touch-Benutzeroberfläche von AEM 6 ist der Entwicklermodus. So wie Autoren und Autorinnen zwischen Bearbeitungs- und Vorschaumodi wechseln können, können Entwickelnde in der Autoren-Benutzeroberfläche in den Entwicklermodus wechseln. Auf diese Weise können Sie die Renderzeit für jede Komponente auf der Seite sehen und Stacktraces von Fehlern sehen. Weitere Informationen zum Entwicklermodus finden Sie in dieser CQ Gems-Präsentation.
Verwendung von rlog.jar zum Lesen der Anfrageprotokolle
Für eine eingehendere Analyse der Anforderungsprotokolle auf einem AEM-System können die von AEM erzeugten request.log-Dateien mit rlog.jar durchsucht und sortiert werden. Diese JAR-Datei ist Teil der AEM-Installation im Ordner /crx-quickstart/opt/helpers. Weitere Informationen zum rlog-Tool und zum Anfrageprotokoll im Allgemeinen finden Sie in der Dokumentation Überwachung und Wartung.
Das Tool „Abfrage erläutern“
Mit dem Tool „Abfrage erläutern“ in ACS AEM-Tools können Sie die beim Ausführen einer Abfrage verwendeten Indizes anzeigen. Dieses Tool ist nützlich bei der Optimierung langsamer Abfragen.
PageSpeed-Tools
Die PageSpeed-Tools von Google bieten Website-Analysen zur Einhaltung der Best Practices in Bezug auf die seitenbezogene Leistung sowie ein Plug-in, das zur weiteren Optimierung neben dem Dispatcher in einer Apache-Instanz installiert werden kann.
Siehe die PageSpeed Tools-Website.
Autorenumgebung
Durchführen von Tests
Um Leistungstests für die Authoring-Umgebung durchzuführen, müssen Sie das Erlebnis der Produktionsautoren simulieren. Die Authoring-Installationen müssen also alle Komponenten, OSGi-Bundles, Benutzeroberflächenanpassung, benutzerdefinierten Indizes und sonstigen Ergänzungen für die produktionsbezogenen Authoring-Instanzen umfassen.
Es gibt viele Automatisierungs-Frameworks, die auf Leistungs- und Belastungstests ausgelegt sind. Benutzerdefinierte Skripte können in diesen Tools aufgezeichnet und dann wiedergegeben werden, um eine Spitzenanzahl von Autoren und Autorinnen zu simulieren, die gleichzeitig ähnlichen Inhalt erstellen und Aktivierungen durchführen. Es wird empfohlen, das Tough Day-Tool zu verwenden, um Aktivitäten wie das Hochladen Tausender Assets oder das Aktivieren einer großen Anzahl von Seiten zu simulieren.
Für die Umgebungstypen, für die ein hohes Laden von Assets oder Erstellen von Seiten erforderlich ist, ist es unerlässlich, Tools wie Tough Day zu verwenden. Auf diese Weise wird sichergestellt, dass die Umgebung auch bei Spitzenbelastung effizient arbeitet. WebDAV ist ein Tool, für das kein Scripting erforderlich ist und mit dem große Mengen an Assets geladen werden können.
MongoDB-spezifische Schritte
Auf Systemen mit MongoDB-Backends stellt AEM mehrere JMX-MBeans zur Verfügung, die bei Auslastungs- oder Leistungstests überwacht werden müssen:
- Die MBean Konsolidierte Cache-Statistiken. Sie können wie folgt direkt darauf zugreifen:
https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D6%2Cname%3D%22Consolidated+Cache+statistics%22%2Ctype%3D%22ConsolidatedCacheStats%22
Für den Cache mit der Bezeichnung Document-Diff sollte die Trefferrate bei einem Wert von über .90 liegen. Wenn die Trefferrate unter 90 % fällt, müssen Sie wahrscheinlich die Konfiguration DocumentNodeStoreService ändern. Der Produktsupport von Adobe kann Ihnen optimale Einstellungen für Ihre Umgebung empfehlen.
- Die Mbean Oak-Repository-Statistiken. Sie können wie folgt direkt darauf zugreifen:
https://server:port/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D16%2Cname%3D%22Oak+Repository+Statistics%22%2Ctype%3D%22RepositoryStats%22
Im Abschnitt ObservationQueueMaxLength wird die Anzahl der Ereignisse in der Oak-Beobachtungswarteschlange während der letzten Stunden, Minuten, Sekunden und Wochen angezeigt. Suchen Sie im Abschnitt „per hour“ nach der größten Anzahl von Ereignissen pro Stunde. Vergleichen Sie diese Zahl mit der Einstellung oak.observation.queue-length. Wenn die höchste für die Beobachtungswarteschlange angezeigte Anzahl die Einstellung queue-length übersteigt:
- Erstellen Sie eine Datei mit dem Namen
com.adobe.granite.repository.impl.SlingRepositoryManager.cfg, die den Parameteroak.observation.queue‐length=50000enthält. - Platzieren Sie sie im Ordner „/crx-‐quickstart/install“.
NOTEDie Standardeinstellung ist 10.000, aber für die meisten Bereitstellungen ist eine Anhebung auf 20.000 oder 50.000 erforderlich.
Veröffentlichungsumgebung
Durchführen von Tests
Der wichtigste Teil einer Bereitstellung, der Belastungstests unterzogen werden muss, ist die Veröffentlichungs- oder Dispatcher-Umgebung für Endbenutzerinnen und -benutzer.
Die Leistung der Website kann mithilfe automatisierter Test-Tools von Drittanbietern überprüft werden. Über diese Tools können Sie die Schritte aufzeichnen, die Benutzerinnen und Benutzer auf der Website durchführen, und viele dieser Sitzungen gleichzeitig ausführen, um die für eine Produktions-Website typische Auslastung zu simulieren.
Die meisten Produktions-Websites verfügen über Optimierungsfunktionen wie Dispatcher-Caching und ein Content Delivery Network. Stellen Sie beim Testen sicher, dass diese Optimierungen auch für die Testumgebung verfügbar sind. Überwachen Sie nicht nur die Reaktionszeiten der Endbenutzerinnen und -benutzer, sondern behalten Sie auch die Systemmetriken auf den Veröffentlichungs-Servern und Dispatchern im Auge, um sicherzustellen, dass das System nicht durch Hardware-Ressourcen eingeschränkt wird.
Auf einem System, das keine umfassende Personalisierung erfordert, sollte der Dispatcher die meisten Anforderungen zwischenspeichern. Daher sollte die Belastungskurve für die Publishing-Instanz relativ flach bleiben. Wenn ein hohes Maß an Personalisierung erforderlich ist, wird empfohlen, Technologien wie iFrames oder AJAX-Anforderungen für personalisierte Inhalte zu verwenden, um ein Maximum an Dispatcher-Caching zuzulassen.
Für grundlegende Tests kann Apache Bench verwendet werden, um die Antwortzeiten von Webservern zu messen und Lasten für das Messen von Dingen wie etwa Speicherverlusten zu erzeugen. Weitere Informationen liefert Ihnen das Beispiel in der Dokumentation zur Überwachung.