Testmethoden und -ergebnisse

Es wurden manuelle Tests in Kombination mit automatisierten Auslastungstests durchgeführt, um zu untersuchen, wie sich eine Fehlkonfiguration der Kartenausdehnung und der Sichtbarkeit des Layer-Maßstabs auf die Performance des Bearbeitungs- und Anzeige-Workflows und die User Experience auswirkt. Desktop-Computerinstanzen sowie ArcGIS Pro und die Web-Apps wurden überwacht, während Workflows unter Last durchgeführt wurden.

Skripttests wurden durchgeführt, um die Schritte zu simulieren, die ein Editor beim Ausführen der definierten Workflows ausführt. Nach Abschluss des Tests wurden die Ergebnisse zusammengestellt und analysiert, um die Desktop-Auslastung und die Effizienz der Endbenutzer mit verschiedenen Hardwarekonfigurationen zu vergleichen.

Testmethoden

Um die Auswirkungen zu testen, die Kartenausdehnungen und Layer-Sichtbarkeitsbereiche auf die Performance und User Experience haben können, wurden einige Änderungen an ansonsten gut konfigurierten Karten vorgenommen, die zuvor getestet und deren Performance und User Experience für gut befunden wurden:

• Die Dashboard-Webkarte (wird für den Workflow “Anzeigen von Assets” verwendet): Die Sichtbarkeit des Strom-Layers wurde von Stadtteilebene auf Landkreisebene geändert, und die Standardausdehnung der Karte wurde von Stadtteil auf Landkreise geändert.
• Das Experience Builder-Web-App (wird für den Workflow “Zusammenfassen von Assets” verwendet): Die Sichtbarkeit des Stromleitungs-Layers und die Standardausdehnung der Karte wurden mit denselben Einstellungen wie oben aktualisiert.
• Die ArcGIS Pro-Projektkarte (wird für Bearbeitungs-Workflows verwendet): Die Sichtbarkeitsbereiche des Layers “Mittelspannungsleiter” innerhalb des Gruppen-Layers “Stromleitung” wurden entfernt, und die Standardausdehnung der Karte wurde auf 1:500.000 festgelegt.

Diese Änderungen wurden gewählt, um die Auswirkungen von Konfigurationen für Kartenausdehnung und Layer-Sichtbarkeit auf verschiedene Arten von grundlegenden Workflows für das Informationsmanagement von Versorgungsnetzen anzuzeigen. Der schreibgeschützte Utility Network-Service, der für Viewer-Workflows verwendet wird, wird auf dem Hosting-Server ausgeführt, während für Bearbeitungs-Workflows der UN-Service verwendet wird, der auf dem GIS-Server gehostet wird. Daher sind die Auswirkungen einer schlecht konfigurierten Layer-Sichtbarkeit und Kartenausdehnung auf die Bearbeitungs- und Anzeige-Workflows an der Instanz der jeweiligen Systemkomponente zu sehen.

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

Das System wurde in drei Szenarien getestet, um zu verstehen, wie sich eine schlechte Kartenkonfiguration auf die Performance und die User Experience bei verschiedenen Lasten auswirkt. Für jedes Lastszenario können Sie die Auswirkungen relativ zu einem ansonsten identischen System mit optimierten Sichtbarkeitsbereichen (links) vergleichen. Auf übergeordneter Ebene zeigen die Testergebnisse, dass Karten mit nur ein oder zwei ungeeigneten Konfigurationen der Layer-Sichtbarkeit oder Kartenausdehnung die Systemauslastung und die User Experience stark beeinträchtigen können, insbesondere bei höheren Lasten.

Testszenario: 2-fache Auslegungslast

Beobachtungen:

• Insgesamt akzeptable Auslastung über alle Systemkomponenten hinweg, jedoch mit doppelter Auslastung der Datenbank-, Utility Network(UN)- und Hosting-Server-Instanzen im Vergleich zum optimierten System
• Hosting- und UN-Server weisen während der gesamten Ausführung CPU-Auslastungsspitzen auf.
• Die Wartezeiten des Services und die ArcSOC-Auslastung bleiben innerhalb akzeptabler Schwellenwerte.

Testszenario: 4-fache Auslegungslast

Beobachtungen:

• Der Hosting-Server und die Datenbank weisen während des gesamten Tests eine signifikante Ressourcenauslastung auf, die im Vergleich zum optimierten System etwa viermal so hoch ist.
• Die PostgreSQL-Instanz zeigt eine mehr als 200 % erhöhte Ressourcenauslastung im Vergleich zur 2-fachen Auslegungslast.
• Die Wartezeiten des Services nehmen weiter zu.
• Die meisten ArcSOCs auf dem Hosting-Server sind während der gesamten Ausführung ausgelastet, wobei einige Instanzen Höchstwerte erreichen.
• Die ArcSOCs auf dem UN-Server zeigen einen linearen und allmählichen Anstieg, der im Vergleich zum Hosting-Server weniger stark beeinträchtigt wird.

Testszenario: 8-fache Auslegungslast (optimiert) im Vergleich zu 6-fache Auslegungslast (suboptimal)

Beobachtungen:

• Die suboptimale Konfiguration zeigt eine insgesamt schlechte Leistung mit inakzeptablen Wartezeiten des Service, insbesondere für Viewer-Workloads, die auf dem Hosting-Server ausgeführt werden.
• In der suboptimalen Konfiguration weisen die Hosting-Server bei 6-facher Auslegungslast eine etwa viermal so hohe Auslastung wie bei der 8-fachen Auslegungslast auf dem optimierten System auf.
• Die PostgreSQL-Instanz erreicht ihren Schwellenwert bei 6-facher Auslegungslast in der suboptimalen Konfiguration, was mehr als das Doppelte der Auslastung des optimierten Systems bei 8-facher Auslegungslast ist.
• Die meisten ArcSOCs auf dem Hosting-Server erreichen mit der suboptimalen Konfiguration die maximalen Schwellenwerte. Es wird ein ungewöhnliches Verhalten beobachtet, das darauf zurückzuführen ist, dass der Server ausgelastet ist und keine SOC-Auslastungswerte abrufen kann.
• Die ArcSOCs auf dem UN-Server (Editoren) zeigen einen linearen und allmählichen Anstieg, der im Vergleich zum Hosting-Server weniger stark beeinträchtigt wird.

Vergleich der ArcSOC-Auslastung

Eine höhere ArcSOC-Auslastung führt häufig zu einer Verlängerung der Wartezeit des Service, was letztendlich einer effizienten Arbeitsweise der Benutzer im Weg steht. Die ArcSOC-Auslastung wurde über alle Lastszenarien hinweg überwacht. In jedem Test war die ArcSOC-Auslastung im Vergleich zum System mit optimierten Karten deutlich höher. Die folgenden Diagramme veranschaulichen den signifikanten Unterschied bei 4-facher Auslegungslast. Im Vergleich zum optimierten System erhöht sich die ArcSOC-Auslastung auf dem Hosting-Server um etwa das 3- bis 4-Fache und auf dem UN-Server um etwa das Zweifache.

Bedienfreundlichkeit

Um die User Experience zu bewerten, wurde die Dauer der einzelnen Workflow-Schritte erfasst. Wenn es länger dauert, bis die Benutzer Workflows abgeschlossen haben, weist dies darauf hin, dass das System langsamer auf Anfragen reagiert. Das folgende Diagramm zeigt die durchschnittliche Zeit, die Benutzer für einen bestimmten Workflow-Schritt in optimierten und suboptimal konfigurierten Systemen benötigen.

In allen Workflows mit Ausnahme des Lastmanagements nimmt die Gesamtdauer des Workflows mit steigender Last messbar zu. Bei 6-facher Auslegungslast dauert der Workflow “Anzeigen von Assets” etwa fünfzehnmal länger als bei 2-facher Auslegungslast. Der Schritt “Anmelden und Öffnen des Projekts” in den Workflows “Aktualisieren des Assets” und “Strom” dauert am längsten, wobei mit zunehmender Last deutliche Sprünge in der Dauer auftreten. Darüber hinaus weisen die Schritte “Suchen”, “Zoomen auf das Bauteil” und “Flussabwärts verfolgen” bei 6-facher Auslegungslast mehr exponentielle Sprünge in der Dauer auf als bei 4-facher Auslegungslast.