Warum einen Hosted Feature Layer Service testen?
Frühere Community-Artikel zum Leistungstest mit Apache JMeter konzentrierten sich darauf, Map Services über die Exportfunktion zu testen. Allerdings sind Hosted (feature) layers auch eine beliebte Funktion von ArcGIS Enterprise und werden in vielen Implementierungen weit verbreitet genutzt. Zusätzlich basieren Abfragen dieser Layer auf einem "wiederholten" Rasterdesign, das eine höhere Skalierbarkeit im Vergleich zu anderen Visualisierungstechnologien bieten kann. Kombiniert man dies mit der clientseitigen Darstellung der zurückgegebenen Daten, ist es eine Win-Win-Situation.
Da Hosted Feature Services eine bewährte und bevorzugte Servicetechnologie sind, ist es sinnvoll, Feature-Abfragen unter Last zu testen, um deren Skalierbarkeit aus erster Hand zu beobachten.
Herausforderungen beim Testen von Hosted Feature Layer Services
Im Vergleich zum Testen der Export-Kartenfunktion ist das Testen von Hosted Feature Layer Service-Abfragen eine Herausforderung, da die Anfragen programmatisch komplexer sind. Eine Navigationsbewegung "pan" oder ein "zoom" im Webbrowser erzeugt mehrere verschiedene Abfragen, jede mit ihrer eigenen Geometrie. Um dieses Verhalten zu wiederholen, wird der erstellte Lasttest nicht nur eine Anfrage senden, sondern viele und in variierender Anzahl. Hinzu kommt, dass jede Abfrageanfrage in der Transaktion eine einzigartige Geometrie und einen sich ändernden maxAllowableOffset (abhängig vom Kartenmaßstab) hat, was viele bewegliche Teile bedeutet, die verfolgt werden müssen.
Wie testet man einen Hosted Feature Service?
Der USGS Motor Vehicle Use Roads Datensatz
Das Verständnis des Prozesses in diesem Artikel ist am effektivsten, wenn die Schritte reproduziert werden können. Diese Wiederholbarkeit erfordert jedoch den Zugriff auf denselben Datensatz. Die räumliche Größe der Datenquelle muss außerdem groß genug sein, um vernünftige Testdaten zu generieren, aber nicht so groß, dass der Download umständlich wird.
Hier kommt der Motor Vehicle Use Map: Roads-Feature-Layer-Datensatz auf hub.arcgis.com ins Spiel. Die 179K Polylinien-Datensätze der USGS Roads-Daten in WGS 1984 Web Mercator (Auxiliary_Sphere) entsprechen etwa 200MB im gezippten Zustand. Sie werden unter der Creative Commons (CC0)-Lizenz bereitgestellt.
- Anzeige der Roads-Daten aus ArcGIS Pro:
- Großmaßstabsansicht mit aktivierter Beschriftung:
Diese Daten werden von ArcGIS Pro zu einem Hosted Feature Service in ArcGIS Enterprise veröffentlicht oder direkt über Portal for ArcGIS geladen.
Testdatengenerierung
Dieser Test erfordert gute Testdaten zur Verwendung innerhalb des JMeter-Tests.
Um diese Aufgabe anzugehen, wird dringend empfohlen, die sehr ausgezeichneten Load Testing Tools zu verwenden.
Version 1.2.2 fügt neue Funktionen wie das Tool "Generate Query Extents" hinzu, das bei der Generierung von Feature-Service-Testdaten sehr hilfreich sein wird.
Diese Daten nutzen das rasterbasierte Design, was wir wollen. Mit dem rasterbasierten Ansatz werden Umschläge für den gewünschten Bereich hinter den Kulissen erstellt. Diese Umschläge werden dann in die entsprechenden 512x512 Query Extents umgewandelt. Die Anzahl der Abfragen (für jeden Anfangsumschlag) variiert je nachdem, wo sie im Raster liegen... dies ahmt das Serviceverhalten in einem Webbrowser nach.
Verfügbarkeit der Tools in ArcGIS Pro herstellen
Sobald das load-testing-tools -Projekt auf Ihren Rechner heruntergeladen wurde, legen Sie den entpackten Ordner in ein Verzeichnis ab, das von ArcGIS Pro zugänglich ist oder gemacht wird. Wenn Sie bereits eine frühere Version der Load Testing Tools installiert haben, kann diese aktualisierte Version neben dieser installiert werden (allerdings mit einem anderen Ordnernamen) oder den bestehenden Ordner vollständig ersetzen.
Zum Beispiel:
- Legen Sie den Ordner load-testing-tools in C:\Users\[Benutzername]\Documents\ArcGIS ab
- Verwenden Sie die Funktion "Add Folder Connection" aus dem Katalog in ArcGIS Pro, um den Inhalt dieses Verzeichnisses aufzulisten:
Das Tool "Generate Query Extents" kann mit dem Hosted Feature Service arbeiten, einer lokalen Kopie der Daten oder den Daten innerhalb einer Enterprise-Geodatabase.
Hinweis: Das Tool sollte Query Extents aus beliebigen Daten generieren können, benötigt jedoch das Projektionskoordinatensystem WGS 1984 Web Mercator Auxiliary_Sphere (WKID: 3857).
Wählen Sie ein Interessengebiet aus
Wählen Sie ein Interessengebiet auf der Karte aus, für das Testdaten generiert werden sollen. In diesem Beispiel werden die Roads-Daten aus dem Nordwesten der Vereinigten Staaten (nahe den Staatsgrenzen von Idaho und Montana) betrachtet. Der ausgewählte Kartenmaßstab ist 1:1.000.000.
Führen Sie das Tool Generate Query Extents aus
- Beim Ausführen des Tools Generate Query Extents sollten Eingaben ähnlich den folgenden angezeigt werden:
Eingaben für das Tool Generate Query Extents anpassen
Die Standardeingaben wurden wie folgt angepasst:
- Mehrere kleinere und größere Maßstabsstufen wurden entfernt
- Die verbleibenden Maßstabsstufen sind 12, 13 und 14, welche den Kartenmaßstäben 144448, 72224 bzw. 36112 entsprechen
- Die Anzahl der Datensätze für diese Maßstäbe wurde erhöht
- Maßstabsstufe 14 kann je nach Version der Load Testing Tools weggelassen werden (falls fehlt, bitte diese Maßstabsstufe manuell hinzufügen)
- Der Dateiausgabeort sollte etwa folgender sein:
- C:\Users\Benutzername\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
- Klicken Sie auf Ausführen, um das Tool zu starten
Hinweis: Die Dauer zur Generierung der Testdaten hängt von mehreren Faktoren ab wie Anzahl verschiedener Maßstabsstufen, Anzahl der Datensätze (je Maßstabsstufe) und dem aktuellen Kartenmaßstab des Projekts.
Hinweis: Die Generierung von Testdaten mit anderen Datensätzen kann erfordern, andere Maßstabsstufen basierend auf Detailgrad und Merkmalsdichte zu verwenden.
Validierung der generierten Testdaten
Es ist gute Praxis, die generierten Testdaten visuell zu überprüfen. Dies gibt dem Tester Aufschluss darüber, welche räumlichen Anfragen im Lasttest an den Feature Service gestellt werden.
Sobald das Tool erfolgreich abgeschlossen wurde, wird es generieren 3 primäre Datensätze, die von Interesse sind:<\/P>
- Bounding box Feature-Klassen
- Enthält zufällig generierte Interessensgebiete<\/LI>
- Eine Feature-Klasse für jede angeforderte Maßstabsstufe<\/LI><\/UL><\/LI>
- Query Extent Feature-Klassen
- Enthält ein (512x512) Kachelraster, auf dem jede Feature-Abfrage basiert<\/LI>
- Eine Feature-Klasse für jede angeforderte Maßstabsstufe<\/LI><\/UL><\/LI>
- Query Extent CSV-Dateien
- Enthält die generierten Testdaten<\/LI>
- Jede Zeile besteht aus den dynamischen Komponenten einer Feature-Service-Anfrage<\/LI>
- Eine Datei für jede angeforderte Maßstabsstufe<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Laden Sie im Catalog-Panel die bbox_36112 Feature-Klasse in die aktuelle Karte in ArcGIS ProDiese Ausgabe ähnelt sehr den Daten des Tools Generate Bounding Boxes<\/LI><\/UL><\/LI>In diesem Beispiel sind die zufällig generierten Boxen pink dargestelltDiese Bereiche repräsentieren die Bildschirmauflösung eines Benutzers, der Daten vom Feature Service anfordert<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Laden Sie nun im Catalog-Panel die query_extents_36112 Feature-Klasse in die aktuelle Karte, aber hinter (unter) den bbox_36112 Daten<\/LI>In diesem Beispiel sind die Abfrage-Kachelraster-Boxen grün dargestelltDiese Kacheln entsprechen einem Bereich auf der Karte, für den die bboxes Daten anfordern<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Das Hereinzoomen in die Karte kann ein besseres Verständnis der Beziehung zwischen diesen beiden Datensätzen ermöglichen<\/LI>Wie in der untenstehenden Karte zu sehen ist, sind einige bboxes leicht versetzt zueinander, teilen aber dennoch eine gemeinsame Abfragekachel aus dem darunterliegenden Raster<\/LI>Die Koordinaten dieser Abfragekacheln (z. B. aus der query_extent Feature-Klasse) werden in die CSV-Dateien und letztlich in den JMeter Load Test eingehen<\/LI><\/UL>
<\/span><\/P>Ein genauerer Blick auf die bboxes zeigt Details zu ihrer jeweiligen AbfragezusammensetzungZum Beispiel benötigen einige bboxes 12 "unterliegende" Kacheln zur Erfüllung, andere 15 oder 20<\/LI>Wie in der untenstehenden Karte zu sehen ist, benötigt die schwarz hervorgehobene bbox 12 spezifische Abfragekacheln, die rot eingefärbt sind<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P> Hinweis: Das Kachelraster-Design des Feature Service ist eine seiner Hauptstärken, da es Wiederholbarkeit ermöglicht. Diese Wiederholbarkeit kann mit Caching in einer Bereitstellung zur verbesserten Skalierbarkeit genutzt werden. Dies ist mit Export Map nicht möglich.<\/STRONG><\/FONT><\/P>Die Untersuchung der generierten CSV-Dateien zeigt die Endergebnisse dieser Transformation<\/LI>Das Anzeigen der Datei query_extents_36112.csv in einem Texteditor sollte etwas Ähnliches wie das Folgende zeigenJe nach Version der Load Test Tools könnten die CSV-Dateien nach der Spalte operationid sortiert sein<\/LI><\/UL><\/LI><\/UL>
- Je nach Version der Load Testing Tools kann die Zeile nach der Spalte operationid gruppiert oder nicht gruppiert sein<\/LI>
- Das Verständnis der operationid ist in diesem Fall ein wichtiges Testkonzept, da jede Operation eine Navigationsaktion darstellt (z. B. ein Schwenken oder Zoomen)<\/LI>
- Aus Sicht von JMeter ist eine Operation dasselbe wie eine Transaktion
- Alle Zeilen mit einer übereinstimmenden operationid werden unter demselben Transaction Controller zu Geometrien von Feature Service Query-Anfragen zusammengefasst<\/LI>
Operationsschleife und Parameterbefüllung<\/H3>Mit einer gewählten operation id liegt der Fokus auf der Schleifenlogik, bei der der Test die Anzahl der Feature Services-Abfragen ermittelt, die die Transaktion ausmachen. Von dort aus wird eine dritte Gruppe von JSR223 Samplern verwendet, um die Anforderungsparameter zu befüllen, die mit der zuvor ausgewählten operation id bei jeder Iteration in der Schleife verbunden sind. <\/P>Es gibt einen JSR223 Sampler für jeden Kartenmaßstab, der die zugehörigen JMeter-Variablen basierend auf der operation id und dem Iterationswert befülltDiese Elemente werden dann zu Schlüssel-Wert-Paaren, die vom HTTP Request aufgenommen werden<\/LI>Die Iterationswerte werden durch ein Counter Config Element verfolgt<\/LI>Diese JSR223 Sampler müssen nicht bearbeitet werden, um den Test auszuführen<\/LI><\/UL><\/LI>Jeder Loop Controller, Counter, JSR223 Sampler und HTTP Request-Objekte sind alle innerhalb eines entsprechenden Transaction Controllers platziert, um die Elemente für jeden Kartenmaßstab logisch zu trennen<\/LI><\/UL>
<\/span><\/P>HTTP Request<\/H3>Im Wesentlichen existiert all die oben beschriebene Testlogik nur für diese Komponente des Tests. Hier kann das JMeter HTTP Request-Objekt die JMeter-Variablen für spezifische Schlüssel-Wert-Parameter lesen, die unmittelbar davor vom JSR223 Sampler befüllt wurden.<\/P>Da dieser Ansatz sehr programmatisch ist, gibt es nur einen HTTP Request pro Kartenmaßstab! Ein solches Design fördert die Wartbarkeit.<\/P>
<\/span><\/P>Hinweis: Dieser Testansatz würde auch für traditionelle, nicht gehostete Feature Layer Services funktionieren. Allerdings haben diese Feature Services nicht dieselben Optimierungen bei den Anforderungsparametern wie gehostete Services, wie z.B. maxAllowableOffset und quantizationParameters. Diese Optionen müssten einfach aus dem HTTP Request gelöscht werden.<\/STRONG><\/FONT><\/SPAN><\/P>Die Thread Group-Konfiguration<\/SPAN><\/H1>Der JMeter-Testplan ist derzeit für einen relativ kurzen Test von 10 Minuten konfiguriert. Allgemein gesprochen performen gehostete Feature Services gut, sodass innerhalb jedes Schritts (1 Minute pro Schritt) sowie im gesamten Test viel Durchsatz stattfinden wird.<\/P>Unterschiedliche Umgebungen und Daten können eine alternative Einstellung erfordern, um die gewünschten Testergebnisse zu erzielen; passen Sie diese nach Bedarf an<\/LI><\/UL>
<\/span><\/P>Validierung des Testplans<\/H1>Als bewährte Praxis ist es immer eine gute Idee, die zurückkommenden Ergebnisse vor der Ausführung des eigentlichen Lasttests zu validieren.<\/P>Verwenden Sie den View Results Tree Listener zur Unterstützung bei der ValidierungDer Testplan enthält einen View Results Tree Listener, aber dieser ist standardmäßig deaktiviertAktivieren Sie ihn, um die Ergebnisse anzusehen<\/LI><\/UL><\/LI><\/UL><\/LI>Starten Sie den Test über die GUI<\/LI><\/UL>Transaktionen <\/H2>Wählen Sie eine der "HFS" Transaktionen ausDie Ergebnisse sollten wie folgt aussehen:<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>In diesem Beispiel wurden die oben aufgeführten Transaktionen: HFS (mapscale: 72224), HFS (mapscale: 36112) und HFS (mapscale: 144448) alle erfolgreich abgeschlossen.
erfolgreichDas Ergebnis des Samplers listet einige weitere Details auf.
In diesem Fall lagen die HFS-Transaktionen für alle Maßstäbe unter einer Sekunde (unter 1 Sekunde)
- Sogar gegen Ende des Tests, unter der höchsten Belastung, lag die durchschnittliche Antwortzeit unter 225 ms oder 0,225 Sekunden
Abschließende Gedanken
Es gibt andere Möglichkeiten, Abfragen eines gehosteten Feature-Layer-Dienstes zu testen, z. B. durch aufgezeichneten Datenverkehr von einem Webbrowser während der Interaktion mit dem Endpunkt oder der Anwendung. Dies würde eine Liste der Service-URLs erzeugen, die in einen Test übersetzt werden könnten. Ein programmatischer Ansatz wie der in diesem Artikel aufgeführte bietet jedoch eine Strategie zum Testen eines großen räumlichen Bereichs des Dienstes, der viele mehr Ausdehnungen abdeckt, als es mit dem Ansatz des aufgezeichneten Datenverkehrs praktisch möglich ist.
Der programmatische Ansatz ist auch leichter zu warten, da die Größe des Testplans viel kleiner ist. Um dies ins Verhältnis zu setzen: Der im Artikel enthaltene JMeter-Test enthielt nur 3 HTTP-Anfragen (je eine für jeden Kartenmaßstab).
Apache JMeter veröffentlicht unter der Apache Lizenz 2.0. Apache, Apache JMeter, JMeter, die Apache-Feder und das Apache JMeter-Logo sind Marken der Apache Software Foundation.
