Benchmark ArcGIS Enterprise...Der ursprüngliche Ansatz
Vor einiger Zeit habe ich die Verwendung des Natural Earth-Datensatzes mit einem vorkonfigurierten Apache JMeter-Test besprochen, um eine ArcGIS Enterprise-Bereitstellung zu benchmarken. Die Ergebnisse dieses Tests konnten dann mit Läufen anderer Bereitstellungen verglichen werden, um eine vergleichende Vorstellung von der Leistung und Skalierbarkeit der zugrunde liegenden Hardware zu erhalten. Dieser Ansatz hatte einige Vorteile:
- Natural Earth ist ein kostenloser GIS-Datensatz
- Für die öffentliche Nutzung verfügbar
- Niedrige bis mittlere Datenkomplexität (einfach zu handhaben)
- Der Testplan enthielt eine schrittweise Last zur Beobachtung der Skalierbarkeitsfähigkeiten
Obwohl nützlich und ein guter Maßstab, bedeutete die Skalierbarkeitskomponente, dass der Test typischerweise lange lief (was auch einige Komplikationen hinzufügte). Ich hatte mich gefragt, ob es einen einfacheren Weg gibt, nur die Verarbeitungshardware (z.B. die CPU) aber dennoch über ArcGIS Enterprise zu benchmarken:
- War es möglich, JMeter aus einer nur Performance-Perspektive zu verwenden?
- Konnte ich einen Test erstellen, um ArcGIS Enterprise ohne einen zugrunde liegenden FGDB- oder Enterprise-Geodatabase-Datensatz zu benchmarken (was den Gesamtaufwand vereinfachen sollte)?
Es stellte sich heraus, dass die Antworten ja waren!
Benchmark ArcGIS Enterprise...Ein alternativer Ansatz
Okay...Ich spreche in Halbwahrheiten. Der neue Benchmark-Test hängt nicht von einem FGDB- oder eGDB-Datensatz-basierten Dienst ab, benötigt aber einige Daten. Um die Dinge einfach zu halten, werden die Daten (z.B. vorab generierte Geometrien) einfach durch die JMeter-Sample-Elemente an eine ArcGIS-Ressource weitergegeben, die keinen referenzierten Datensatz im Hintergrund hat.
Wie wird das also gemacht?
Durch den bewährten Geometry service. Der Geometry service von ArcGIS Server ist eine integrierte Ressource, die Zugriff auf viele Funktionen zur Durchführung geometrischer Operationen bietet. Die Berechnungen dieser Operationen (wie Puffer oder Generalisieren) können einfach oder komplex sein (je nachdem, was man anfragt). Aus Sicht eines Performance-Analysten bietet er ein fantastisches Mittel zum Benchmarking der CPU-Hardware der Maschine, auf der ArcGIS Server läuft.<\/SPAN>
Hinweis: Obwohl der Begriff ArcGIS Enterprise auch ArcGIS Server einschließt, beansprucht dieser Benchmark hauptsächlich letzteres (z.B. ArcGIS Server). Ein Teil des Verkehrs kann über den ArcGIS Web Adaptor laufen und es findet eine kleine Menge an Portal for ArcGIS Authentifizierung statt, aber das Gros der Arbeit wird per Design von ArcGIS Server ausgeführt.<\/STRONG>
Vorteile der Verwendung des Geometry service
Der Geometry service gibt es in ArcGIS Server seit Version 9.3, er ist also allgegenwärtig. Das macht einen Test mit ihm einfach und zuverlässig. Da die Daten, die den Test antreiben, in den Schlüssel-/Wert-Paaren der Anfragen enthalten sind, erhöht das die Portabilität (z.B. kein Datensatz zum Mitnehmen).
Hinweis: Obwohl der Geometry service schon seit einiger Zeit mit ArcGIS Server enthalten ist, ist er standardmäßig ausgeschaltet und läuft nicht. Der Dienst muss gestartet und für die entsprechenden Portal for ArcGIS-Mitglieder freigegeben werden, bevor der Test ausgeführt wird.<\/STRONG>
Der Geometry_Functions_Benchmark Testplan
- Das Herunterladen und Öffnen des Testplans in Apache JMeter sollte ähnlich wie folgt aussehen:
- Passen Sie die User Defined Variables an Ihre Umgebung an
Welche Arten von Funktionen sollten getestet werden?
Für einen Benchmark lautet die kurze Antwort: nur wenige. Dieser spezielle Testplan ruft nur wenige verschiedene Operationen auf... sowie dieselben Operationen auf unterschiedliche Weise (z.B. Änderung von Anfrageparametern, um absichtlich eine Variantenantwort zu erhalten). Das sorgt für Variabilität, sodass der Test nicht immer dasselbe tut.
Unten sehen Sie die im Benchmark verwendeten Operationen:
Erwartete Test- und Operationsleistung
Dieser Test enthält einige Operationen, die schnell ausgeführt werden können und andere, die mehr Zeit benötigen. Diese Geschwindigkeit variiert je nach Hardware. Letztendlich wollen wir nur wenige Minuten lang ArcGIS Enterprise (z.B. Server) laufen lassen, um eine Vorstellung von der Verarbeitungsleistung zu bekommen. Wenn jede Operation 10 Minuten dauern würde (und der Test viel länger), könnte der Benchmark selbst zu zeitaufwendig und weniger praktisch werden.
Beispiel für Bereitstellungsarchitektur
Dieser Benchmark-Test wurde in einem Labor gegen zwei verschiedene Server ausgeführt (z.B. einmal pro Server):
- ArcGIS Enterprise -- Maschine #1 (ältere Hardware)
- Intel Xeon E5-4650, 2,70 GHz
- SPECint_base2006
- Punktzahl: 50,5
- 32 Prozessorkerne
- HyperThreading deaktiviert
- 64GB RAM
- 10Gbps Netzwerk
- ArcGIS Enterprise -- Maschine #2 (neuere Hardware)
- Intel Xeon Gold 6126, 2,60 GHz
- SPECint_base2006
- Punktzahl: 71,9
- 24 Prozessorkerne
- HyperThreading deaktiviert
- 128GB RAM
- 10Gbps Netzwerk
Hinweis: Da sich dieser Test mehr auf Geschwindigkeit als auf Durchsatz konzentrierte, wurden SPECint_base-Zahlen anstelle von SPECint_rate_base verwendet.<\/STRONG>
Ausführung des Benchmark-Tests
Für lang laufende Tests wird nicht empfohlen, den Testplan innerhalb der GUI auszuführen. Da dies jedoch ein relativ kurzer Test ist, ist die Auswirkung gering.
Hinweis: Bei der Durchführung eines Tests wird stets empfohlen, Startzeit und erwartete Dauer mit dem zuständigen Personal abzustimmen. Dies gewährleistet minimale Auswirkungen auf Benutzer und andere Kollegen, die möglicherweise ebenfalls das betreffende ArcGIS Enterprise Site (z.B. die Produktionsbereitstellung) nutzen müssen. Außerdem hilft dies dabei, Systemrauschen durch andere Aktivitäten und Nutzung zu vermeiden, welches die Testergebnisse "verunreinigen" könnte.<\/STRONG>
Ergebnisse
Nach Anpassung der User Defined Variables zur Ausrichtung auf die entsprechende Umgebung (Maschine #1…devlab05) wurde der Benchmark direkt in der JMeter-GUI ausgeführt. Die Ergebnisse können im Element View Results in Table beobachtet werden:
- Zur Bequemlichkeit berechnet der Testplan automatisch die Gesamtdauer des Testlaufs direkt im Namen der letzten Operation
- Dies macht die Benchmark-Zeit leicht aus der Tabelle ablesbar
< LI >Der Testplan wurde angepasst um auf einen Server mit neuerer Hardware (Maschine #2…eistsrv05) zu zeigen und der Benchmark wurde erneut ausgeführt< /SPAN >< UL >< LI >< SPAN >Aus der Tabelle wurden die Ergebnisse nach dem ersten Lauf hinzugefügt:< /SPAN >< / LI >< / UL >< / LI >< / UL >< P >< SPAN >< span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="jmeter_geometry_functions_benchmark_results_server2.png" style="width: 999px;"><\/span><\/SPAN><\/P>Wie erwartet benötigte die erste Maschine mehr Zeit, um dieselben Operationen abzuschließen. Dies führte zu einem messbaren Leistungsunterschied zwischen den beiden Maschinen.<\/SPAN><\/P>- Maschine #1…devlab05
- Benchmark-Dauer: 259946 ms<\/LI><\/UL><\/LI>
- Maschine #2…eistsrv05
- Benchmark-Dauer: 181441 ms<\/LI><\/UL><\/LI><\/UL>
Prozentuale Veränderung berechnen<\/H2>Da die Antwortzeiten mit neuerer Hardware niedriger (z.B. schneller) waren (im Vergleich zum ersten Lauf auf älterer Hardware), berechnen wir eine prozentuale Abnahme<\/EM>:<\/P>Zuerst Original-Serverzeit - neuere Serverzeit = die Abnahme<\/LI>Dann die Abnahme ÷ Original-Serverzahl × 100 = die % Abnahme<\/LI><\/UL>(259946 ms - 181441 ms) / 259946 ms = 0,302<\/P>0,302 × 100 = 30,2% <\/P>Die Benchmark-Zeiten der älteren Hardware (unser Ausgangspunkt) waren 30 % niedriger als bei der neueren Hardware<\/U>. Diese prozentuale Veränderung deutet auf eine messbare Verbesserung bei Verwendung der neueren Hardware hin.<\/P>Schätzung der prozentualen Veränderung basierend auf SPEC<\/H2>Wir verwenden das SPEC-Verhältnis mit der Benchmark-Zeit des ursprünglichen Laufs, um die Zielzeit (Benchmark-Zeit auf der neueren Maschine) vorherzusagen. Dies kann helfen zu verstehen, ob ungefähr dieselbe prozentuale Veränderung geschätzt werden kann.<\/P>(Baseline_SPEC × Baseline_Time) = (Target_SPEC × Target_Time)<\/P>((Baseline_SPEC × Baseline_Time) / Target_SPEC) = Target_Time<\/P>(36,875 × 259946 ms) / 53,75 = 178335 ms (nach Abrunden auf die nächste Sekunde)<\/P>(259946 ms - 178335 ms) / 259946 ms = 0,314<\/P>0,314 × 100 = 31,4%<\/P>Aus dieser Vorhersage wurde geschätzt, dass die ältere Hardware um 31 % langsamer war als die neuere Hardware. Dies liegt sehr nahe an der prozentualen Veränderung, die basierend auf den beobachteten Benchmark-Zeiten berechnet wurde.<\/U> <\/P>Zukünftige Hardware<\/H1>
<\/span>Prozessorarchitekturen und CPU-Geschwindigkeiten verbessern sich ständig. Schließlich<\/EM> könnte ein solcher Benchmark-Test (so wie er derzeit aufgebaut ist) nur noch eine Minute oder einige Sekunden dauern (was für ein tolles Problem). Zu diesem Zeitpunkt könnte dem Test Komplexität hinzugefügt werden, um seine Laufzeit zu verlängern und besser an die neue Technologie anzupassen.<\/P>Sie haben vielleicht bemerkt, dass die letzte Transaktion im Test deaktiviert wurde. Diese Anfrage für einen 1000-Punkt-Puffer mit einer Distanz von 10000 Metern und einer Einheit von 9035 (International Meter Distance) benötigt einige Zeit zur Berechnung (selbst auf ordentlicher Hardware). Sie wurde deaktiviert, um die Laufzeit auf eine vernünftige Dauer zu verkürzen. Falls hilfreich, kann sie je nach CPU-Geschwindigkeit der interessierenden Bereitstellung als zusätzliche Berechnung aktiviert werden.<\/P>Abschließende Gedanken <\/H1>Wie in anderen Community-Artikeln erwähnt, gibt es keinen einzelnen Dienst oder keine Funktion, die die gesamte Breite und Tiefe von ArcGIS abdecken kann. Der Geometry-Service ist jedoch eine Ressource, die einen Teil des erstaunlichen GIS-Bereichs repräsentiert und einfach zu handhaben ist. Das macht ihn zu einer guten Option für Benchmark-Testbemühungen.<\/P>Eine schnelle Antwortzeit hängt doch nur von der CPU-Geschwindigkeit ab, oder?<\/H2>Für diesen Geometry-Benchmark-Test ja. Für reale Dienste ist die Verarbeitungsgeschwindigkeit jedoch nicht der einzige Faktor.<\/P>Server-Hardwarekomponenten wie Festplattengeschwindigkeit, verfügbarer Speicher und Netzwerkgeschwindigkeit sind weitere Ressourcen, die Antwortzeiten verbessern können (zusätzlich zur CPU-Geschwindigkeit). Zusammen wirken sie sich positiv auf das Benutzererlebnis aus.<\/P>Dieser Benchmark konzentrierte sich auf die CPU-Leistung, da sie einen großen Teil des Client-Anfrage/Server-Antwort-Prozesses ausmacht. Wie gerade erwähnt ist sie jedoch nicht die einzige Server-Ressource bei Berücksichtigung anderer potenzieller ArcGIS-Dienste.<\/P>Was ist mit anderen CPU-Vergleichstools?<\/H2>
<\/span>Es gibt viele Dienstprogramme, die verschiedene Teile der Server-Hardware mit einer ganzen Reihe von Tests profilieren und prüfen können. Diese Tests sind großartig und bieten sicherlich Mehrwert beim Verständnis der Hardware. Nochmals: Es gibt keinen einzelnen Test, der alle GIS-Aspekte abbilden kann. Aber hoffentlich kann dieser Geometry Benchmark Test Plan ein nützliches Werkzeug im Werkzeugkasten eines Analysten sein. <\/P>
<\/P>Um den in diesem Artikel verwendeten Apache JMeter Testplan herunterzuladen, siehe: geometry_functions_benchmark1.zip<\/A><\/STRONG> <\/P> <\/P>
<\/P>
<\/P>
Zuschreibung<\/STRONG><\/P>Ressource:
Datei:Wikimedia_Foundation_Servers-8055_43.jpg<\/A><\/P>Beschreibung: Rackmontierte PowerEdge-Server der 11. Generation<\/SPAN><\/P>Autor:
Victorgrigas<\/A> - Eigenes Werk<\/SPAN><\/P>Erstellt: 16. Juli 2012<\/SPAN><\/P>Hochgeladen: 20. Juli 2012<\/SPAN><\/P>Lizenz: CC BY-SA 3.0<\/A>, Link<\/A> <\/P> <\/P>
Ressource:
Datei:Cpu-processor.jpg<\/A><\/P>Beschreibung:<\/P>
Autor:
Fx Mehdi<\/A> - Eigenes Werk<\/SPAN><\/P>Hochgeladen: <\/SPAN>30. Mai 2019<\/SPAN>
Lizenz: Creative Commons Attribution-Share Alike 4.0 International
