Schlussfolgerungen und wichtige Erkenntnisse

Während der fünf Testausführungen wurde klar, dass die mit zu wenig Ressourcen ausgestattete Datenbankinstanz aus der ersten Testausführung die System-Performance und User Experience deutlich beeinträchtigte. Nachdem die Datenbankinstanz richtig für die vorliegenden Arbeitslasten dimensioniert wurde, hatte das Verhältnis von ArcSOCs zu vCPU einen geringeren Einfluss auf die Workflow-Ausführungszeiten. Ein Blick auf die folgende Tabelle zeigt, dass das 1:1-Verhältnis von ArcSOCs zu vCPU zusätzliche Wartezeiten (0,246 s) bei den Anzeige-Workflows verursachte, jedoch keine wesentlichen Auswirkungen auf Bearbeitungs-Workflows hatte (siehe P99 Waits HS). Das liegt wahrscheinlich an ausgelasteten ArcSOCs auf dem Hosting-Server.

Das Verhältnis von 2:1 führte zu nahezu identischen Workflow-Ausführungszeiten ohne nennenswerte Wartezeiten, war jedoch auch mit einer hohen Speicherauslastung auf dem UN-GIS-Server (82 %) verbunden. Ein Verhältnis von 2:1 ist für diese versionierten Bearbeitungs-Workflows zu hoch, da maximal 7 ArcSOCs auf dem UN-GIS-Server ausgelastet werden. Daher werden durch die Erhöhung von ArcSOCs auf dem UN-GIS-Server nur unnötig Serverressourcen belegt. Der Hosting-Server, der Nur-Anzeigen-Workflows unterstützt, hatte dagegen keinerlei Probleme mit dem 2:1-Verhältnis. Der UN-GIS-Server benötigt mehr Speicher, um ein Verhältnis von 2:1 und höher zu unterstützen. Bei 4:1 benötigt dann auch der Hosting-Server zusätzlichen Speicher.

Ressourcenauslastung

Wir kamen zu dem Schluss, dass das Hinzufügen weiterer Service-Instanzen nicht zu einer besseren User Experience bei der Bearbeitung führte, es aber tatsächlich die Reaktionsgeschwindigkeit in den Anzeige-Workflows verbessern kann, indem es die Wartezeiten verkürzt. Wir stellten fest, dass selbst ungenutzte ArcSOCs Serverressourcen belegten. Die Tabelle oben zeigt, dass die Workflowzeiten leicht steigen, wenn sich das Verhältnis von ArcSOCs zu vCPU erhöht.

Dies impliziert, dass die zusätzlichen verfügbaren ArcSOCs für die Unterstützung der Benutzeranforderungen nicht erforderlich waren und unnötigerweise Systemressourcen (hauptsächlich Speicher) belegten. Die Tabelle oben bestätigt, dass Bearbeitungs-Workflows die zusätzlichen ArcSOCs nicht nutzten, die Anzeige-Workflows mit einer deutlich höheren Anzahl von Vorgängen pro Stunde dagegen schon. Daher wurde das Optimum unseres Systems für Nur-Anzeige-Services auf dem Hosting-Server bei einem Verhältnis von 2:1 zwischen ArcSOCs und vCPUs erreicht, während das Optimum auf dem UN-GIS-Server ein Verhältnis von 1:1 war.

Wichtige Erkenntnisse

• Eine mit zu wenig Ressourcen ausgestattete Datenbankinstanz wirkte sich negativ auf das gesamte System aus:

  • Bei unserem System haben wir festgestellt, dass die größere Geodatabase-Instanz (16 vCPUs) entscheidend ist.

  • ArcSOCs, GIS-Server-CPU und Web Adaptors waren ausgelastet, sodass Performance-Probleme anscheinend das gesamte System betrafen.

  • Die Workflow-Ausführung dauerte bei einer mit zu wenig Ressourcen ausgestatteten Datenbank etwa doppelt so lange.

  • Eine mit zu wenig Ressourcen ausgestattete Datenbank beeinträchtigte die Performance deutlich stärker als schlecht konfigurierte Karteninstanzen.

  • Allein die Erhöhung der Datenbankressourcen verbesserte das Verhalten und die Performance des Systems erheblich.

• Eine Erhöhung des Verhältnisses von ArcSOCs (Kartenservice-Instanzen) zu vCPU führte bei ausreichend mit Ressourcen ausgestatteten Datenbanken nicht zu einer Verbesserung der User Experience von Endbenutzern oder der Workflow-Ausführungszeiten.

• Das Hinzufügen nicht erforderlicher Service-Instanzen kann das System negativ beeinflussen, indem unnötigerweise zusätzliche Ressourcen belegt werden.

• Eine Erhöhung der Anzahl der ausgeführten Karteninstanzen wirkt sich auf die Speichernutzung des GIS-Servers aus, selbst wenn sie nicht ausgelastet sind.

• Arbeitslasttrennung ist weiter ein wichtiger Punkt – Feature-Services, die versionierte Daten bereitstellen, benötigen mehr GIS-Server-Speicher als Nur-Anzeige-Services.

  • Die verfügbaren Ressourcen (CPU, RAM und Datenträger-E/A) auf der Datenbankinstanz führten dazu, dass die Last vom gesamten System wesentlich besser verarbeitet werden konnte.

• Überwachen Sie mindestens die Datenbank-CPU, ArcSOC-Auslastung, GIS-Serverressourcen und User Experience, um die optimale Konfiguration für Ihr System zu ermitteln, insbesondere nach Änderungen.