Testergebnisse zu den Auswirkungen der ArcSOC-Konfiguration

Neben einer Bewertung der Datenbankressourcen konzentrierte sich die zweite Testreihe darauf, eine optimale ArcSOC-Konfiguration zu identifizieren, die eine 8-fache Auslegungslast unseres Systems und seiner Workflows unterstützt. Hierbei wird davon ausgegangen, dass ausreichend Datenbankressourcen zur Verfügung stehen.

Testmethoden und -ergebnisse

Es wurden drei Tests mit unterschiedlichen Verhältnissen von ArcSOCs zu vCPU durchgeführt:

• 2:1, or two ArcSOCs per vCPU on the ArcGIS Server instances
• 3:1, or three ArcSOCs per vCPU on the ArcGIS Server instances
• 4:1, or four ArcSOCs per vCPU on the ArcGIS Server instances

Dieser Test wurde auch mit einem 1:1-Verhältnis von ArcSOCs zu vCPU durchgeführt. Weitere Informationen dazu finden Sie in der Beschreibung des Tests von großen Datenbankinstanzen in der Bewertung der Auswirkungen von Datenbankressourcen.

Es wurden mehrere Lasttests durchgeführt, bei denen systematisch das Verhältnis von ArcSOC-Instanzen zu vCPUs variiert wurde, um die Auswirkungen auf die Performance und User Experience zu beobachten und zu messen. Alle anderen Aspekte des Systems wurden nicht geändert, um sinnvolle Ergebnisse zu erzielen.

Performance-Kennwerte wie ArcSOC-Nutzung und -Verfügbarkeit, Service-Wartezeiten, Auslastung der Systemressourcen und error -Raten wurden überwacht, um die einzelnen Konfigurationen bewerten zu können.

Die Tests wurden mit der 8-fachen (8x) Auslegungslast der ursprünglichen Systemteststudie durchgeführt, und die ArcGIS Enterprise-Serverressourcen wurden halbiert, um sicherzustellen, dass genügend Last vorhanden war, um das System zu beeinträchtigen. Es wurde JMeter verwendet, um die Workflows der Benutzer zu simulieren und die System-Performance unter verschiedenen Lasten zu messen.

Da es sich bei ArcGIS um ein mehrschichtiges System handelt, wurden 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.

2:1 ArcSOCs : vCPU ratio

Bei dieser Ausführung wurden zwei ArcSOCs pro vCPU für die ArcGIS Server-Instanzen konfiguriert. In diesem Fall waren das 16 ausgeführte ArcSOCs und 8 vCPUs. Wie in den vorherigen Diagrammen ist die prozentuale Auslastung der CPU orange, der Festplatte gold und des Speichers lila.

Im unten dargestellten Diagramm liegt die CPU aller Maschinen im Allgemeinen bei unter 60 %. Allerdings können Sie auch sehen, dass die Speicherauslastung auf dem UN-GIS-Server Spitzenwerte von über 80 % aufweist. Dies liegt an den zusätzlich ausgeführten ArcSOCs im Vergleich zu einem 1:1-Verhältnis. Die Services auf dem UN-GIS-Server ermöglichen eine versionierte Datenbankbearbeitung. Auch wenn das System scheinbar reibungslos läuft, muss der Speicher genau überwacht werden, um Probleme zu vermeiden. Das Diagramm über gleichzeitige Anforderungen zeigt durchschnittlich 35 gleichzeitige Anzeigeanforderungen (rot), die stetig geöffnet und geschlossen werden.

Das unten dargestellte Diagramm zeigt die ArcSOC-Nutzung für den Hosting-Server, wobei 16 ArcSOCs ausgeführt werden (die blaue Linie wird von der grünen Linie überdeckt). Die maximale Nutzung (ausgelastet) liegt bei 14. Der UN-GIS-Server (nicht gezeigt) verfügte über maximal 7 ausgelastete ArcSOCs und nutzte die zusätzlichen Service-Instanzen nicht, sodass sich von den 16 ausgeführten ArcSOCs die meisten im Leerlauf befanden. Da dieser Server eine Speicherauslastung von über 80 % aufwies, könnte eine Reduzierung der Service-Instanzen auf min./max. 8 auf dem UN-GIS-Server den Druck auf die Speicherressourcen verringern und das System optimal auf diese Workflows und Lasten auslegen. Jede Änderung der Workflows oder Last könnte dieses Gleichgewicht stören.

3:1 ArcSOCs to vCPU ratio

Bei dieser Ausführung wurden drei ArcSOCs pro vCPU konfiguriert. In diesem Fall waren das 24 ausgeführte ArcSOCs und 8 vCPUs. Auch hier liegt die CPU-Auslastung (orange) auf allen Maschinen im Allgemeinen bei unter 60 %. Leider erreicht die Speicherauslastung (lila) auf dem UN-GIS-Server das Maximum, wobei die Einbrüche auf 95 % im Rahmen des Bereinigungsprozesses auftreten. Gleichzeitige Anzeigeaufforderungen (rot) werden stetig geöffnet und geschlossen, ihre Zahl liegt bei durchschnittlich 36. Dieses System scheint die Last zu bewältigen, ist aber aufgrund der Speicherknappheit nicht nachhaltig.

Darüber hinaus können Sie durch einen Blick auf das folgende ArcSOC-Diagramm erkennen, dass der UN-GIS-Server bei einem Verhältnis von 3:1 über 24 ausgeführte ArcSOCs verfügt (die blaue Linie wird von der grünen Linie überdeckt). Die maximale Auslastung beträgt jedoch nur 18, sodass auch bei Nichtbenutzung Speicher beansprucht wird. Dies ist ein Beispiel für eine schlechte Konfiguration. Die Arbeitslast erfordert nicht alle verfügbaren ArcSOCs. Die sechs nicht benötigten ArcSOCs (24 ausgeführte minus 18 ausgelastete) belegen unnötigerweise ebenfalls Ressourcen (Speicher). Eine Erhöhung des Speichers auf dem UN-GIS-Server könnte zu einer Verbesserung dieser Situation führen, möglicherweise wären jedoch auch Probleme mit der CPU oder Datenbank die Folge. Tests und Beobachtungen sind erforderlich, um geeignete Konfigurations- und Designentscheidungen zur Unterstützung des Systems zu treffen.

4:1 ArcSOCs to vCPU ratio

Bei dieser Ausführung wurden vier ArcSOCs pro vCPU konfiguriert. In diesem Fall waren das 32 ausgeführte ArcSOCs und 8 vCPUs auf dem UN-GIS-Server. Die CPU-Auslastung (orange) steigt, es gibt zwei Spitzenausschläge von über 80 % auf dem UN-GIS-Server. Das größte Problem ist jedoch die Speicherauslastung (blau) von nahezu 100 % für diese Instanz. Selbst der Bereinigungsprozess kann hier kaum Abhilfe schaffen.

Im Folgenden sehen Sie, dass gleichzeitige Anzeigeaufforderungen (rot) weiterhin stetig geöffnet und geschlossen werden. Auch hier liegt der Durchschnittswert wie beim 3:1-Verhältnis bei 36. Dies zeigt, dass die zusätzlichen ArcSOCs keinen zusätzlichen Nutzen für die Performance oder User Experience der Endbenutzer des Systems bringen. Stattdessen werden dadurch nur weitere GIS-Serverressourcen belegt.

Dies wird zusätzlich durch das folgende ArcSOC-Diagramm bestätigt, das maximal 16 ausgelastete ArcSOCs zeigt. Daraus geht eindeutig hervor, dass das Hinzufügen zusätzlicher Service-Instanzen nur unnötig Serverressourcen belegt und keine Vorteile für die Performance oder User Experience mit sich bringt. Eine Erhöhung der UN-GIS-Server-CPU und des Speichers kann die Ergebnisse verbessern, jedoch auch dazu führen, dass das Problem zur CPU des Datenbankservers verlagert wird. Tests und Beobachtungen sind von entscheidender Bedeutung.