Testmethoden und -ergebnisse

Es wurden Tests durchgeführt, um sicherzustellen, dass das Design die erwartete Performance erbringt und die Workflows, Benutzer und die beabsichtigte Last unterstützt. Systemtests bieten die Möglichkeit, Probleme bei der Bereitstellung des Systems in “niederen” Umgebungen zu festzustellen und zu beheben, idealerweise bevor sie im Produktivsystem auftreten. Bei dieser Teststudie lag der Schwerpunkt der Teststrategie darauf, zu bewerten, ob das System die Workflows unterstützt, und zu verstehen, wie sich die Last auf das System, die zugehörigen Komponenten und die User Experience von Endbenutzern auswirkt.

Bei der Durchführung der Workflows unter verschiedenen Lastszenarien wurde jede Komponente überwacht. Nach Abschluss des Tests wurden die Ergebnisse zusammengestellt und analysiert, um sowohl Engpässe als auch überlastete Komponenten im System zu identifizieren. Diese Informationen wurden verwendet, um Systemkomponenten zu identifizieren, die vor weiteren Tests hoch- , herunter- oder horizontal skaliert werden mussten.

Manuelle Tests der User Experience wurden durchgeführt, indem Bildschirmaufzeichnungen der Workflow-Tester aufgezeichnet wurden, um sicherzustellen, dass die Benutzer des Systems ihre Workflows produktiv abschließen konnten.

Weitere Informationen finden Sie unter Entwerfen einer effektiven Teststrategie.

Geschwindigkeit von Workflows

In dieser Teststudie wurde ein Geschwindigkeitsmodell auf die getesteten Workflows angewendet. Das Geschwindigkeitsmodell zeigt, wie der Test das Arbeitstempo in einer Organisation zur Flurstücksverwaltung simulieren soll, in der Workflows als eine bestimmte Anzahl von Vorgängen pro Stunde in einem Team von Mitarbeiterressourcen ausgeführt werden. Diese Strategie basierte auf Rückmeldungen von Esri Kunden und zielte darauf ab, das Szenario eines mittleren Flurstückverwaltungskunden abzubilden, auf dem die Daten basierten.

Während des einstündigen Testzeitraums wurden die Workflows verteilt und gestaffelt ausgeführt, um eine gleichzeitige Initiierung zu vermeiden, wobei dennoch Überlappungen möglich waren. Auf diese Weise wurde der Ablauf von Aufgaben in realen Umgebungen nachgebildet. Im unten dargestellten Geschwindigkeitsmodell sehen Sie, wie wir die Geschwindigkeit und die Anzahl der Vorgänge pro Stunde für die einzelnen Workflows angegeben haben. Diese beiden Komponenten definieren die “Auslegungslast” des Systems.

Die Last wurde anschließend durch die Vervielfältigung der Workflows bis zu einem Punkt erhöht, an dem das System nicht mehr in der Lage war, akzeptable Reaktionszeiten oder die erfolgreiche Umsetzung der Workflows zu gewährleisten. Im vorliegenden Fall war dies der Punkt, an dem die Last groß genug war, um bewerten zu können, ob das System für den beabsichtigten Organisationstyp geeignet war. Beachten Sie, dass das in dieser Teststudie angewendete Workflow-Geschwindigkeitsmodell möglicherweise nicht der typischen Nutzung in Ihrer Organisation entspricht.

Werkzeuge für Performance-Tests

Da es sich bei ArcGIS um ein mehrschichtiges System handelt, wurden Performance-Tests auf Client-, Service- und Datenspeicherebene sowie für die zugrunde liegende Infrastruktur selbst durchgeführt. In dieser Teststudie wurde JMeter verwendet, um die Workflows der Benutzer zu simulieren und die Systemleistung unter verschiedenen Lasten zu messen. ArcGIS Pro-Anforderungen wurden aufgezeichnet und dann wiedergegeben, um die Auslastung zusätzlich zu den manuellen Workflows zu simulieren, die zur Bewertung der User Experience der Endbenutzer durchgeführt wurden. Windows Performance Monitor und ArcGIS Monitor wurden ebenfalls verwendet, um die Ressourcenauslastung der verschiedenen Komponenten zu überwachen.

Weitere Informationen finden Sie unter Werkzeuge für Performance-Tests.

Testergebnisse

Diese Architektur wurde mit automatisierten Lasttests und manuellen Benutzern in drei Szenarien überprüft. Die Ergebnisse der einzelnen Szenarien finden Sie unten. Allgemein zeigen die Testergebnisse, dass das System in seiner Implementierung ausreichend ausgestattet ist, um Lasten bis zum 8-Fachen der Auslegungslast zu bewältigen. Die Tests haben auch gezeigt, wie wichtig die richtige Anwendungs- und Systemkonfiguration für die Performance ist.

Testszenario: Auslegungslast

Observations:

• Das System hat die Last unterstützt
• Die Hosting-Server (Anzeige-Workflows) lagen im Durchschnitt bei einer CPU-Auslastung von weniger als 30 % (orange Linien)
• Die Flurstücksserver (Bearbeitungs-Workflows) lagen im Durchschnitt bei einer CPU-Auslastung von unter 40 %
• SQL Server weist eine sehr geringe CPU-Auslastung auf, die im Allgemeinen bei unter 15 % bleibt
• Der Spitzenwert bei der Festplattennutzung in der SQL Server-Instanz ist auf einen Hintergrundprozess von Windows zurückzuführen (goldfarbene Linien)
• Die Daten zu gleichzeitigen Anforderungen zeigen, dass das System etwa 3 gleichzeitige Anzeigeanforderungen (rot) und 1 gleichzeitige Bearbeitungsanforderung (blau) zu einem beliebigen Zeitpunkt während des Testzeitraums unterstützt

Testszenario: 4-fache Auslegungslast

Observations:

• Das System unterstützte die Last mit einem marginalen Anstieg der Ressourcennutzung bei den Komponenten
• Hosting-Server liefen in der Regel mit weniger als 40 % CPU-Auslastung im Durchschnitt
• Flurstücksserver liefen in der Regel mit weniger als 50 % CPU-Auslastung im Durchschnitt
• Der SQL Server blieb in der Regel bei unter 40 % CPU-Auslastung
• Regelmäßige Spitzenwerte bei der Festplattennutzung lassen sich auf startende Workflows oder spezifische Workflow-Schritte zurückführen. Konkret ist der Spitzenwert zwischen 15:10 Uhr und 15:20 Uhr mit dem Workflow zum Zusammenfassen von Flurstücken verbunden, da dazu mehrere Dashboards gleichzeitig geöffnet werden.
• Die Daten zu gleichzeitigen Anforderungen zeigen, dass das System im Durchschnitt 10 bis 15 gleichzeitige Anzeigeanforderungen und Bearbeitungsanforderungen während des gesamten Testzeitraums unterstützt, wobei es größere Spitzenlasten durch gleichzeitige Anzeigeanforderungen gibt, die sehr schnell wieder geschlossen werden.

Testszenario: 8-fache Auslegungslast

Observations:

• Das System unterstützt die Last mit einem erwarteten Anstieg der Ressourcennutzung bei den Komponenten
• Hosting-Server bleiben in der Regel bei weniger als 50 % CPU-Auslastung
• Flurstücksserver bleiben in der Regel bei weniger als 50 % CPU-Auslastung
• SQL Server weist einen deutlichen Anstieg der Ressourcennutzung auf und erreicht konstant etwa 60 % CPU-Auslastung.
• Die Daten zu gleichzeitigen Anforderungen zeigen, dass das System dauerhaft Spitzenwerte von 35 gleichzeitigen Anzeigeanforderungen und durchschnittlich zwei gleichzeitige Bearbeitungsanforderungen während des Testzeitraums unterstützt.
• Der Anstieg der Leseanforderungen um 20:20 Uhr ist der Beginn des Workflows für das Zusammenfassen von Flurstücken.

Konfiguration von Service-Instanzen

Neben der Ressourcennutzung durch virtuelle Maschinen wurde auch die ArcSOC-Nutzung bei den einzelnen Testausführungen überwacht, um besser verstehen zu können, ob die Services richtig abgestimmt waren. Bei allen Ausführungen bis zur 8-fachen Auslegungslast waren stets deutlich weniger als die maximal möglichen ArcSOCs (16) ausgelastet, was darauf hindeutet, dass mehr Karteninstanzen als notwendig für diese Lasten konfiguriert wurden. Wenn dies eine Produktionsumgebung mit Lasten unter der 8-fachen Auslegungslast wäre, könnten wir die Größe des Hosting-Servers und der GIS-Servercomputer reduzieren, um Geld zu sparen. Dazu müsste die ArcSOC-Nutzung zusammen mit der Server-CPU und dem Serverspeicher überwacht werden, um erkennen zu können, wann eine Skalierung zum Decken des Bedarfs erforderlich ist. Außerdem müsste sichergestellt sein, dass wir diese Computer nicht überlasten, denn jeder ArcSOC belegt Speicher und jeder ausgelastete ArcSOC nutzt eine virtuelle CPU.

Aus dem folgenden Diagramm geht hervor, dass alle 16 ArcSOCs bei 8-facher Auslegungslast zu bestimmten Zeiten auf der Hosting-Server-Site ausgelastet sind. Wenn alle ArcSOCs ausgelastet sind, würden wir erwarten, dass die Wartezeiten für die Services steigen (was auch beobachtet wurde). Allerdings zeigt der Flurstücksserver (rechts) eine geringere ArcSOC-Auslastung an, es werden nur maximal 9 der 16 konfigurierten ArcSOCs verwendet.

Der anfängliche Spitzenwert auf dem Hosting-Server (links) wurde durch die Dashboards verursacht, die zu Beginn des Tests gestartet wurden. Wir haben die Workflow-Geschwindigkeit für zukünftige Testausführungen korrigiert und Dashboard-Starts auf einen Zeitraum von mehreren Minuten verteilt, um eine realistischere Situation abzubilden.

• Weitere Informationen finden Sie im Blog The Art and Science of ArcSOC Optimization.

User Experience – Zeiten manueller Workflows

Neben automatisierten Workflows beobachteten wir auch die User Experience durch die Erfassung von Bildschirmaufzeichnungen der Workflow-Tester. Wir extrahierten die Dauer der Workflows (wie lange die Benutzer für alle Schritte in einem Workflow benötigten) aus diesen Aufzeichnungen. Diese Methode dient dazu, sicherzustellen, dass die Benutzer des Systems ihre Workflows produktiv nutzen können.

Wie Sie der untenstehenden Grafik entnehmen können, sind die Workflow-Zeiten weitgehend vergleichbar; es gibt nur geringfügige Abweichungen in allen Testszenarien. Das zeigt, dass das System die erhöhte Last tragen kann, ohne die von den Endbenutzern wahrgenommene Reaktionsfähigkeit des Systems negativ zu beeinflussen.

User Experience – Zeiten manueller Workflow-Schritte

Zusätzlich zu den Workflows selbst wurden auch die Workflow-Zeiten wichtiger Schritte in allen Workflows erfasst. Dies stellt die durchschnittliche Zeit dar, die benötigt wurde, um einen bestimmten Schritt eines Workflows durchzuführen, während das System unter Last ausgeführt wurde. Im untenstehenden Diagramm sehen Sie ein Beispiel für den Workflow zum Zusammenführen von Flurstücken, bei dem die Zeiten für das Ausführen der einzelnen Schritte in allen Lastszenarios sehr konstant waren. Dieses Muster ist mit geringen Abweichungen in allen Workflows zu beobachten.

Schlussfolgerungen und wichtige Erkenntnisse

Die Tests wurden in einer Testumgebung und nicht in einem Produktionssystem durchgeführt. Ihr System verfügt wahrscheinlich über andere Workflows, eine abweichende Konfiguration oder ein anderes Design. Beispielsweise wird in Azure normalerweise kein Web Adaptor (bei Verwendung von SAML) verwendet und das AppGateway verteilt die Last direkt auf die Server. Sie können aus diesen Testansätzen und -ergebnissen jedoch Ihre eigenen Schlüsse ziehen:

• Der Fokus auf Beobachtbarkeit im gesamten System liefert wertvolle Informationen, mit denen sich die Performance gegenüber den Infrastrukturkosten richtig abzustimmen lässt. Auch für andere kritische Aktivitäten wie die Fehlerbehebung sind sie sehr hilfreich.
• Überwachen Sie die Serverressourcen Ihrer Systeme, die ArcSOC-Auslastung und die Bearbeitungszeiten des Workflows – sowohl während des Tests (in einer Staging-/Test-Umgebung) als auch in der Produktion.
• Achten Sie auf Fehlanpassungen bei Ressourcen und der Ressourcennutzung. Beispiel:
  • Bei der 8-fachen Auslegungslast scheint die Hosting-Server-Site für diese Menge an Anforderungen angemessen dimensioniert zu sein. Allerdings verfügen die GIS-Server (Flurstücksserver) immer noch über viele ungenutzte Ressourcen.
  • Es gibt mehrere Möglichkeiten, die Infrastruktur herunterzuskalieren, um Kosten zu sparen, ohne dabei Abstriche bei der Performance oder User Experience in Kauf nehmen zu müssen.
  • Außerdem lassen sich die ArcSOCs so neu konfigurieren, dass eine optimalere Verteilung zur Unterstützung unserer Workflows erzielt wird.