Testergebnisse zu den Auswirkungen von Datenbankressourcen
In unserer ersten Testreihe haben wir uns die Auswirkungen der Datenbankressourcen auf die Fähigkeit des Systems angesehen, die Last zu bewältigen, auch mit umfangreichen GIS-Serverressourcen. Dies soll zeigen, welche Auswirkungen die Datenbank im gesamten System hat. Mit anderen Worten: Wenn Ihre Benutzer lange Wartezeiten erleben, liegt das Problem nicht unbedingt ausschließlich auf der ArcGIS Server-Ebene.
Hinweis:
Diese Tests wurden mit einer optimierten Datenbankkonfiguration durchgeführt, um hervorzuheben, dass eine Datenbank mit den richtigen Ressourcen eine entscheidende Rolle für die Gesamtperformance des ArcGIS-Systems spielen kann. In Ihren eigenen Systemen sollten Sie sich jedoch darauf konzentrieren, Ihre Datenbank zu optimieren und abzustimmen, bevor Sie Ihre Hardware hochskalieren. Die Verbesserung der Datenbank-Performance durch Optimierung ist oft kostengünstiger und kann als schlecht wahrgenommene Performance-Probleme beheben, ohne zusätzliche Investitionen in die Infrastruktur erforderlich zu machen.
Testmethoden und -ergebnisse
Wir haben zwei Tests durchgeführt, um zu vergleichen, wie Datenbankressourcen die System-Performance beeinflussen, selbst mit genügend Serverressourcen:
- zunächst mit einer kleinen virtuellen Maschine mit einer Datenbankinstanz mit 8 vCPUs
- dann mit einer größeren virtuellen Maschine mit einer Datenbankinstanz mit 16 vCPUs
Wir haben alle anderen Aspekte des Systems konstant gehalten, mit einer 1:1-ArcSOC-Konfiguration. Mit anderen Worten: Ein ArcSOC pro vCPU auf der ArcGIS Server-Instanz, wobei die Anzahl der ArcSOCs und vCPUs gleich ist. Wir haben Performance-Kennwerte wie ArcSOC-Nutzung und -Verfügbarkeit, Service-Wartezeiten, Systemressourcenauslastung und error Raten erfasst und überwacht, um jede Konfiguration zu bewerten. Die Tests wurden mit der 8-fachen (8x) Auslegungslast der ursprünglichen Systemteststudie durchgeführt, und die ArcGIS Enterprise-Serverressourcen wurden halbiert (im Vergleich zu unseren vorherigen Teststudien), um sicherzustellen, dass genügend Last vorhanden war, um das System zu beeinträchtigen.
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.
Lasttest 1: kleine Datenbankinstanz – 8 vCPUs
Dieser Lauf wurde mit 8 vCPUs auf der PostgreSQL-Instanz durchgeführt, um die Systemauswirkungen auf einem verkleinerten Datenbankserver zu beobachten. Der ArcGIS GIS Server (UN-Server) wurde ebenfalls mit 8 vCPUs bereitgestellt. Unten finden Sie sechs Diagramme der Instanzressourcen, die die Ressourcenauslastung im gesamten System zeigen, sowie ein Diagramm, das gleichzeitige Anforderungen darstellt. In jedem der Ressourcendiagramme stehen die orangefarbenen Linien für die prozentuale CPU-Auslastung, die goldenen Linien für die prozentuale Festplattenauslastung und die lilafarbene Linie für die prozentuale Speicherauslastung.
Im untenstehenden Diagramm sehen Sie, dass für die PostgreSQl-Datenbank die CPU bei 100 % ausgeführt wird und die Hosting-Server-CPU häufig bis zu 100 % erreicht. Dies liegt an der hohen Anzahl an Anzeigeanforderungen, die mit den Workflows bei der 8x Auslegungslast verbunden sind.
Das untere Diagramm zeigt gleichzeitige Anforderungen, gemessen anhand von JMeter-Protokollen. Beachten Sie die rote Linie, die gleichzeitige Anzeigeanforderungen darstellt und während der Testläufe auf bis zu 538 steigt. Das zeigt, dass Anforderungen nicht geschlossen werden. In späteren Diagrammen sehen Sie, wie sich diese Linie stetig auf und ab bewegt, was darauf hinweist, dass das System reagiert und Anforderungen schnell genug geschlossen werden, um die Last zu bewältigen.
Diese Konfiguration hat die Last nicht unterstützt, da der Datenbankserver zu wenig Ressourcen hatte. Dies wird durch die Menge an Orange (CPU-Auslastung) im PostgreSQL-Datenbankdiagramm, die Spitzen in der Hosting-Server-CPU und die Anzahl gleichzeitiger Anforderungen deutlich.
Um diese Behauptung weiter zu untermauern, zeigt das untenstehende Diagramm die ArcSOC-Auslastung auf dem Hosting-Server, wie sie vom Soccer-Dienstprogramm (ArcSOC Monitoring) erfasst wird, das auf einem Remote-Computer ausgeführt wird. Die rote Linie zeigt ausgelastete ArcSOCs bei 100 % (8), wahrscheinlich auf die überlastete Datenbank zurückzuführen. ArcSOCs werden gehalten (ausgelastet), während sie auf die Antwort der Datenbank warten. Tatsächlich waren die ArcSOCs so ausgelastet, dass Soccer ihren Zustand nicht verfolgen konnte, wie die unvollständige rote Linie und die plötzlichen Rückgänge beim Maximum (grüne Linie) zeigen.
Lasttest 2: große Datenbankinstanz – 16 vCPUs
Im zweiten Test haben wir die PostgreSQL-Datenbankinstanz auf 16 vCPUs verdoppelt, um mögliche Unterschiede zum ersten Test zu beobachten. Die ArcGIS GIS Server wurden jeweils weiterhin mit 8 vCPUs bereitgestellt. Wie im vorherigen Diagramm ist die prozentuale Auslastung der CPU orange, der Festplatte gold und des Speichers lila. Beachten Sie, dass – abgesehen von einigen Spitzen – alle Server im Allgemeinen mit weniger als 60 % CPU, Festplatte und Speicher laufen.
Das Diagramm über gleichzeitige Anforderungen zeigt durchschnittlich 36 gleichzeitige Anzeigeanforderungen mit einigen Spitzen. Die offenen Anforderungen steigen nicht wie im vorherigen Diagramm, was darauf hindeutet, dass dieses System die Last verarbeitet.
Das folgende ArcSOC-Diagramm zeigt, dass ArcSOCs auf dem Hosting-Server ausgelastet sind, aber die Gesamtreaktion des Systems ist gut. Obwohl 99 % (p99) der Nutzung 8 SOCs oder weniger sind, liegt der Durchschnitt bei 4,81. Später sehen wir uns die User Experience an, um herauszufinden, ob Menschen mit dem System effizient arbeiten können.
Bedienfreundlichkeit
Neben der Gesamtauslastung und -performance des Systems verbesserten die umfangreicheren Ressourcen der Datenbankinstanz die Fähigkeit des Endbenutzers, seine Arbeit effizient zu erledigen. Diese Teststudie hat die Effizienz des Endbenutzers bewertet, indem sie die Ausführungszeiten von Workflows beobachtet hat (wie lange ein Benutzer benötigt, um die Schritte des Workflows zu erfüllen, sowie die Ausführungszeiten für Workflow-Schritte). Wie lange hat es gedauert, einen wichtigen Schritt innerhalb eines Workflows abzuschließen.
Hinweis:
Die User Experience ist das ultimative Maß in diesen Teststudien. Wir haben während der Tests festgestellt, dass selbst wenn das System scheinbar innerhalb normaler Parameter funktioniert, Aspekte wie Netzwerklatenz, GPU-Implementierung, Fehlkonfiguration von Karteninstanzen usw. die Endbenutzer negativ beeinflussen können. Konzentrieren Sie sich auf die Endbenutzer, um Ihre Rendite zu verbessern.
Im obigen Diagramm sehen Sie, wie eine erhöhte Systemressourcensättigung im Testlauf mit kleinen Datenbanken zu längeren Workflow-Ausführungszeiten führt, was insgesamt zu einer schlechteren User Experience führt. Die Gesamtausführungszeit aller Workflows erhöhte sich deutlich bei einer Datenbank mit unzureichenden Ressourcen im Vergleich zu einer mit angemessenen Ressourcen, selbst wenn ArcGIS Server über ausreichend Ressourcen verfügt. Insbesondere verzeichnete der Workflow zum Anzeigen von Assets eine dramatische Verkürzung der Workflow-Ausführungszeit bei einer richtig dimensionierten Enterprise-Geodatabase.
Neben der Workflow-Ausführungszeit können wir uns genauer ansehen, wie Datenbankressourcen die Dauer bestimmter Schritte im Bearbeitungs-Workflow beeinflussen. Allerdings zeigt sich im Workflow zum Aktualisieren eines Assets ein großer Unterschied bei der Dauer, ein Projekt zu öffnen und ein Asset zu finden. Ebenso zeigte “Verfolgung für Strom” eine deutliche Zunahme in allen Workflow-Schritten. Dieses Muster hat sich für alle erfassten Workflows fortgesetzt.
