Vorabtests

Vorabtests sind Teil unseres Prozesses, mit dem die Ergebnisse unserer formellen Tests verbessert werden sollen. Vorabtests bieten folgende Vorteile:

• Systemengpässe werden identifiziert, die die Performance und Benutzerfreundlichkeit des Systems unter Last beeinträchtigen könnten.
• Man kann iterativ mit verschiedenen Einstellungen und Konfigurationen experimentieren.
• Der formellere Lasttestprozess kann optimiert werden.

Die anfängliche physische Architektur war nahezu identisch mit einem zuvor getesteten grundlegenden Netzwerk-Informationsmanagementsystem, das mit SAP HANA konfiguriert war. Es wurde lediglich ein zusätzlicher AWS Client VPN-Endpunkt für die Anbindung mobiler Geräte ergänzt. Während der Vorabtests stellten wir fest, dass das System die beabsichtigte Last mit den zusätzlichen Arbeitslasten nicht unterstützen würde, wie unten gezeigt. Die Architektur wurde entsprechend angepasst, wie in der physischen Architektur beschrieben. Nachdem diese Änderungen im Abschnitt Testergebnisse vorgenommen wurden, wurden die hier dargestellten endgültigen Testergebnisse erzielt.

Vorabtest bei 4-facher Auslegungslast

Das System wurde zunächst mit grundlegenden Workflows für das Netzwerk-Informationsmanagement getestet, die ohne mobile Workflows ausgeführt wurden (siehe linke Seite der Abbildung unten). Mit Ausnahme einer Spitze in ArcGIS Web Adaptor 02 zu Beginn des Tests, die auf die Installation von Windows Defender-Updates zurückzuführen ist, ist die Ressourcenauslastung relativ gering.

Vergleichen Sie dies mit der rechten Seite der Abbildung, die zeigt, wie das Hinzufügen mobiler Workflows zusätzlich zur 4-fachen Auslastung in den ArcGIS Web Adaptor- und Portal for ArcGIS-Instanzen zu einer erheblichen CPU-Auslastung führt. Die ArcGIS Web Adaptor-Instanzen erreichen eine Sättigung, die dazu führt, dass die Anforderungsverarbeitung verlangsamt wird oder eine Zeitüberschreitung auftritt. Alle vier GIS-Server und die Datenbank weisen außerdem eine höhere CPU- (orange) und Festplattenauslastung (gold) auf. Dies ist auf den Download-Schritt in den Offline-Workflows zurückzuführen, bei dem der Offline-Bereich von 2,66 GB von zahlreichen Außendienstmitarbeitern heruntergeladen wird.

Die unten (linke Seite) gezeigten offenen Anforderungen allein für die Grundlast verdeutlichen, dass das System die Last verarbeitet. Zu Beginn des Tests sammeln sich einige offene Anforderungen, was sich bei einem Maximum von 19 Redakteuren und 11 Viewers stabilisiert. Wenn jedoch die zusätzliche mobile Last (rechte Seite) hinzugefügt wird, steigt die Zahl auf 42 Desktop-Anforderungen (Viewer und Editoren) und 127 gleichzeitige mobile Anforderungen, bevor die Downloads abgeschlossen sind und die Last abnimmt. Dieses Muster deutet auf eine Verlangsamung während des Download-Schritts des Tests hin, während die Benutzer darauf warten, dass der Download des Offline-Bereichs abgeschlossen ist.

Instanzgrößen

Während des Vorabtests haben wir lange Downloadzeiten für Offline-Bereiche (2,66 GB groß) von über 30 Minuten beobachtet (siehe Abbildung unten). Bei der Fehlersuche stellten wir fest, dass das Problem auf eine sehr hohe CPU-Auslastung der ArcGIS Web Adaptor- und Portal for ArcGIS-Instanzen zurückzuführen war, die den Durchsatz einschränkte und zu einer Zeitüberschreitung bei Downloads führte. Um dieses Problem zu beheben, wurden die ArcGIS Web Adaptor-Instanzen von 2 vCPUs auf 8 vCPUs und die Portal for ArcGIS-Instanzen von 4 vCPUs auf 8 vCPUs erhöht.

Insbesondere der Download-Schritt von nicht verbundenen Workflows profitierte von der höheren Instanzgröße der ArcGIS Web Adaptor- und Portal for ArcGIS-Instanzen, wobei die Downloadzeit um 41 % reduziert wurde. Hierbei handelt es sich jedoch um eine Überkapazität, wenn gerade keine große Anzahl von Downloads ausgeführt wird. In einer Produktionsumgebung würden wir nach einer Möglichkeit suchen, diese Komponenten in Spitzenzeiten zu skalieren und die Instanzgrößen zu reduzieren, wenn sie nicht benötigt werden, um die Kosten zu senken. Um das richtige Gleichgewicht zwischen Performance und Kosten zu finden, ist es daher entscheidend, Ihre Ressourcen zu optimieren und gleichzeitig die Größe von Offline-Karten auszugleichen (sie so klein wie möglich zu machen, während sie den erforderlichen Bereich abdecken),

• Weitere Informationen über Empfehlungen für das Verwenden von Karten offline.

Konfiguration von Service-Instanzen

In ArcGIS Enterprise werden Service-Instanzen eines veröffentlichten Service als ArcSOC-Prozesse bezeichnet. Es gibt verschiedene Möglichkeiten, ArcSOCs zu konfigurieren, um lange Wartezeiten und eine schlechte User Experience zu vermeiden. Wenn die Anzahl ausgelasteter ArcSOCs das einem Service zugewiesene Maximum überschreitet, verlängern sich die Wartezeiten, bis ein ArcSOC verfügbar wird. Wenn jedoch die maximale Anzahl von ArcSOCs für alle Services größer ist als die verfügbaren vCPUs, verlängern sich auch die Wartezeiten, wenn alle vCPUs ausgelastet sind. Daher ist es wichtig, das Verhältnis von ArcSOCs zu verfügbaren vCPUs zu überwachen und zu verwalten, insbesondere wenn Systemänderungen vorgenommen werden.

Da auf den beiden Hosting-Servern 16 vCPUs verfügbar sind, wurden die anfänglichen Einstellungen für die Service-Instanz für den mobilen Versorgungsnetz-Service und den schreibgeschützten Gasversorgungsnetz-Service jeweils auf Folgendes festgelegt:

• Minimum: 8
• Maximal: 8

Da der schreibgeschützte Gasversorgungsnetz-Service während der Vorabtests überwiegend mit maximaler ArcSOC-Auslastung ausgeführt wurde, während für den mobilen Service übermäßig viele ArcSOCs frei waren, stellten wir fest, dass der Service neu konfiguriert werden musste. In den folgenden Abbildungen finden Sie einen Vergleich der ArcSOC-Auslastung vor und nach der Optimierung.

Die Service-Instanzen für den mobilen Versorgungsnetz-Service wurden von einem Minimum und einem Maximum von 8 auf ein Minimum und Maximum von 6 reduziert. Die Service-Instanzen für den Gasversorgungsnetz-Service wurden von einem Minimum und einem Maximum von 8 auf ein Minimum und Maximum von 10 erhöht. Nach der Änderung zeigen die Diagramme eine gleichmäßigere Verteilung zwischen beiden Services, und die Wartezeiten der Nutzer wurden messbar verbessert.

• Weitere Informationen zum Optimieren und Konfigurieren von Services
• Weitere Informationen zum Konfigurieren von Service-Instanz-Einstellungen

Ergebnisse der Vorabtests

Vorabtests des ursprünglichen grundlegenden Netzwerk-Informationsmanagementsystems mit den zusätzlichen mobilen Arbeitslasten halfen dabei, Systemengpässe und Fehlkonfigurationen zu identifizieren und zu korrigieren, die sich andernfalls negativ auf die Systemleistung und die User Experience in einer Produktionsumgebung ausgewirkt hätten. Unsere Vorabtests führten zu den folgenden Systemanpassungen, die vor der Durchführung der formellen Tests eingearbeitet wurden:

• Die Größe der ArcGIS Web Adaptor-Instanzen wurde von 2 vCPUs auf 8 vCPUs erhöht.
• Die Größe der Portal for ArcGIS-Instanzen wurde von 4 vCPUs auf 8 vCPUs erhöht.
• Die Größe der Offline-Bereiche wurde optimiert, um sie so klein wie möglich zu gestalten und gleichzeitig den notwendigen Bereich abzudecken.
• Die ArcSOC-Konfiguration wurde angepasst, um eine gleichmäßigere Verteilung der Auslastung zu gewährleisten und die Wartezeiten sowohl für den mobilen Versorgungsnetz-Service als auch für den Gasversorgungsnetz-Service zu verkürzen.