Network Analyst Route
Einfach ausgedrückt wird der Network Analyst Routenlöser verwendet, um den schnellsten Weg von einem Ort zum anderen zu finden. Dieser zurückgelegte Weg kann nur einen Start- und Endpunkt umfassen, kann aber optional an mehreren Orten stoppen und den Löser auch auffordern, für jede Route in der Lösung eine Schritt-für-Schritt-Anleitung zu erstellen.
Hinweis: Die Routenfunktionalität ist mit einer Network Analyst Lizenz verfügbar.
Lasttest eines Network Analyst Routenservices
Network Analyst ist mit vielen Fähigkeiten und Funktionen für die Routensuche ausgestattet. Solche Lösungen können über ArcGIS Pro ausgeführt werden, werden aber oft über einen ArcGIS Service genutzt. Da es branchenführende Technologie für Routensuchen bietet, ist es logisch, den lokal laufenden (Routen-)Löserservice einem Lasttest zu unterziehen, um sein Skalierungspotenzial zu prüfen.
Es gibt mehrere Arten von Analysen, die von der Network Analyst Erweiterung bereitgestellt werden. Dieser Artikel verwendet Routen, da sie sehr einfach zu handhaben sind... die einzigen erforderlichen Eingaben sind mindestens zwei gültige Haltepunkte. Diese Eigenschaft macht sie zu einer guten Wahl, um zu demonstrieren, wie man Daten generiert und sie in einem Lasttest gegen einen Routenservice verwendet.
Hinweis: Die Schritt-für-Schritt-Anleitung in diesem Artikel verwendete ArcGIS Pro 2.9 mit Network Analyst Services, die in einer ArcGIS Enterprise 10.9 Bereitstellung liefen.
Wie man einen Network Analyst Routenservice testet?
Network Analyst ArcGIS Pro Tutorial-Daten
Das Verständnis der Prozesse in diesem Artikel ist am effektivsten, wenn die Schritte mit denselben Daten nachvollzogen werden können. Für eine solche Aufgabe hat das Network Analyst Team ein großartiges Datenset bereitgestellt.
Es gibt ein Tutorial auf arcgis.com namens Network Analyst ArcGIS Pro Tutorial Data. Gezipped ist es etwa 132MB groß und besteht aus Network Analyst Daten für mehrere verschiedene Städte: San Diego, Paris und San Francisco. Das geografische Koordinatensystem ist: WGS 1984 (WKID: 4326). Die Daten sind öffentlich zugänglich.
Hinweis: Die Beispiele in diesem Artikel konzentrieren sich auf das San Diego Datenset.
- Ansicht der San Diego Straßen-Daten aus ArcGIS Pro (mit Topographischer Basiskarte):

- Die Ebenen Streets, Walking_Pathways oder Network Dataset (NewSanDiego_ND) müssen nicht aktiviert sein, um die Network Analyst Fähigkeiten zu nutzen
- Im obigen Beispiel sind sie aktiviert, um als Referenzpunkt für die San Diego Straßen zu dienen
- Dieser Artikel wird nicht die Details zur Erstellung, Konfiguration oder Veröffentlichung eines Netzwerk-Datasets in ArcGIS Enterprise behandeln. Für Informationen zu solchen Aufgaben siehe:
Hinweis: Die Beispiele des Routenlösers in diesem Artikel verwenden einen Kartenservice (mit der Netzwerk-Analyse-Fähigkeit) im Gegensatz zu einem Geoverarbeitungsservice. Der Kartenservice nutzt synchrone Ausführung.
Testdatengenerierung
Für diesen Test werden gültige Haltepunkte benötigt, die im JMeter-Test verwendet werden können.
Wie bei anderen JMeter-Artikeln in der Community benötigen wir gute Testdaten, um den größten Nutzen aus den Ergebnissen zu ziehen. Und wie zuvor erledigen die Load Testing Tools diese Aufgabe schnell. Es gibt sogar ein spezielles Tool zur Erstellung von Routendaten.
Version 1.3.0 fügt einige schöne Verbesserungen zum Tool "Generate Data (Solve Route)" hinzu.
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, 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 daneben platziert werden (allerdings mit einem anderen Ordnernamen) oder die vorherige Version vollständig ersetzen.
Zum Beispiel:
- Legen Sie den Ordner load-testing-tools in C:\Users\[Benutzername]\Documents\ArcGIS ab
- Verwenden Sie die Funktion "Ordnerverbindung hinzufügen" im Katalog von ArcGIS Pro, um den Inhalt dieses Verzeichnisses anzuzeigen:

Das Tool "Generate Data (Solve Route)" kann Testdaten aus dem (Karten-)Service, einer lokalen Kopie der Daten oder den Daten innerhalb einer Enterprise-Geodatabase erstellen. Für dieses Beispiel können beliebige Daten in WGS 1984 (WKID: 4326) mit einem Interessengebiet rund um San Diego verwendet werden.
Starten des Tools Generate Data (Solve Route)
- Beim Starten des Tools Generate Data (Solve Route) sollte eine Benutzeroberfläche ähnlich der folgenden angezeigt werden:

- In seiner einfachsten Form muss nur der Pfad zur CSV-Datei angegeben werden, die die Haltepunkte enthalten wird
- Wir möchten zwar zufällige Punkte als Haltepunkte generieren, aber vermeiden, dass sie in Buchten, Seen oder Ozeanen erzeugt werden
- Dafür gibt es den optionalen Parameter Constraining Polygon
- Dieses Eingabefeld kann verwendet werden, um eine Datenebene zu referenzieren und räumlich einzuschränken, wo die Punkte generiert werden sollen
- Tatsächlich werden wir alle Standardwerte anpassen
- Ansicht des Polygons (in Pink), das das Interessengebiet der San Diego Straßendaten in ArcGIS Pro umreißt:

Hinweis: Dieses Polygon wurde manuell erstellt und ist nicht im San Diego Datensatz enthalten
- Um die im Artikel verwendete Shapefile SanDiegoPolygon herunterzuladen siehe: SanDiegoPolygon.zip
Hinweis: Aus Sicht des Testens muss das Polygon nicht jeden Segment der Straßenebene einschließen
Eingaben des Tools Generate Data (Solve Route)
- Passen Sie die Anzahl der Tests an auf:
- Passen Sie die Haltepunkte pro Test an auf:
- Legen Sie das Constraining Polygon fest auf:
- Legen Sie den Ausgabeort auf einen Dateipfad fest, an dem die Ergebnisse gespeichert werden:
- C:\Users\[Benutzername]\Documents\ArcGIS\Projects\NetworkAnalystMap1\sandiegostops1.csv
- Klicken Sie auf Ausführen, um das Tool zu starten

< LI >Beim Prüfen der CSV-Datei werden die generierten Haltepunktdaten
Die Version von ArcGIS Enterprise (ArcGIS Server)
- Einige Versionen fügen neue Funktionen hinzu
- Dieser Test basiert auf dem veröffentlichten Dienst aus dem San Diego-Datensatz und ArcGIS Enterprise 10.9< / LI > < / UL > < / LI > < / UL > < / LI > < / UL > < P >< FONT face = "inherit " > Verschiedene Netzwerkdatensätze können unterschiedliche Anforderungsparameteroptionen < / FONT > verfügbar < FONT face = "inherit " > oder < / FONT > ausgefüllt sein < FONT face = "inherit " > standardmäßig. Einige Parameter, wenn aktiviert (wie returnDirections), weisen den Solver an, mehr Informationen zurückzugeben. Dies fordert den Dienst wiederum auf, mehr Arbeit zu leisten, was die Antwortzeit der Anfrage erhöht.< / FONT >< / P >< P >< FONT color = "#FF0000 " >< STRONG >< FONT face = "inherit " > Hinweis: Die Ansicht der HTTP-Anfrage aus dem Inhaltsverzeichnis (linke Seite des Testplans) erscheint als Mischung aus JMeter-Variablen und Zeichenfolgen. Dies ist beabsichtigt. Diese Werte werden bei der Wiedergabe (im View Results Tree-Objekt und der Rohdaten-Datei) gefüllt.< / FONT >< / STRONG >< / FONT >< / P >< H2 id = "toc-hId-1852051304 " >< SPAN > Die Thread Group-Konfiguration < / SPAN >< / H2 >< P > Der JMeter-Testplan ist für einen Lasttest von 20 Minuten konfiguriert. Bei diesem Testbeispiel mit zwei Stopps pro Routenanforderung sollte der Solver gut funktionieren und eine gute Anzahl von Stichproben (z.B. Antworten vom Server) für jeden Schritt zurückgeben.< / P >< UL >< LI > Unterschiedliche Umgebungen und Daten können alternative Einstellungen erfordern, um die gewünschten Testergebnisse zu erzielen; passen Sie die Thread-Einstellungen nach Bedarf an< / LI >< / UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center " image-alt = "jmeter_routesolve_threadgroup.png " style = "width: 999px; " >< img src = "https:\/\ /us.v-cdn.net\ /6038851\ /uploads\ /images\ /30250i41B8B7EC7961DE05\ /jmeter_routesolve_threadgroup.png " role = "button " title = "jmeter_routesolve_threadgroup.png " alt = "jmeter_routesolve_threadgroup.png " \/ >< \/ span >< \/ P >< H1 id = "toc-hId--84485878 " > Validierung des Testplans < \/ H1 >< P > Es ist eine bewährte Methode, die Ergebnisse innerhalb der JMeter-GUI zu validieren, bevor der eigentliche Lasttest über die Befehlszeile ausgeführt wird.< \/ P >< UL >< LI > Verwenden Sie den View Results Tree Listener zur Unterstützung bei der Validierung< UL class = "lia-list-style-type-circle " >< LI > Der Testplan für diesen Artikel enthält einen View Results Tree Listener, ist jedoch deaktiviert< UL class = "lia-list-style-type-square " >< LI > Aktivieren Sie ihn, um die Ergebnisse bei Ausführung des Tests aus der GUI anzuzeigen< \/ LI >< \/ UL >< \/ LI >< \/ UL >< \/ LI >< LI > Starten Sie den Test aus der GUI< UL class = "lia-list-style-type-circle " >< LI > Lassen Sie den Test etwa 20 Sekunden laufen< UL class = "lia-list-style-type-square " >< LI > Klicken Sie auf Stopp< \/ LI >< \/ UL >< \/ LI >< \/ UL >< \/ LI >< \/ UL >< H2 id = "toc-hId--1762857622 " > Transaktionen < \/ H2 >< UL >< LI > Wählen Sie eine der „Route“-Transaktionen< UL class = "lia-list-style-type-circle " >< LI > Der View Results Tree-Bereich sollte wie folgt aussehen:< \/ LI >< \/ UL >< \/ LI >< \/ UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center " image-alt = "jmeter_route_transaction.png " style = "width: 999px; " >< img src = "https:\/\ /us.v-cdn.net\ /6038851\ /uploads\ /images\ /30246iAE729CCE513C09FC\ /jmeter_route_transaction.png " role = "button " title = "jmeter_route_transaction.png " alt = "jmeter_route_transaction.png " \/ >< \/ span >< \/ P >< UL >< LI > In diesem Beispiel wurden alle Transaktionen erfolgreich abgeschlossen< UL class = "lia-list-style-type-circle " >< LI > Manchmal können beim Stoppen der Wiedergabe die letzten Transaktionen im View Results Tree fehlschlagen, da sie „mitten in einer Anfrage“ gestoppt wurden; dies kann ignoriert werden< \/ LI >< \/ UL >< \/ LI >< \/ UL >< H2 id = "toc-hId-724655211 " > Anfragen < \/ H2 >< UL >< LI > Erweitern Sie eine der „Route“-Transaktionen< LI > Wählen Sie die HTTPS-Anfrage darin aus< UL class = „lia-list-style-type-circle“ > < LI > Die Ergebnisse sollten wie folgt aussehen:< \/ LI > < \/ UL > < \/ LI > < \/ UL > < P > < span class=„lia-inline-image-display-wrapper lia-image-align-center“ image-alt=„jmeter_route_request1.png“ style=„width: 999px;“> < img src=„https:\/\ /us.v-cdn.net\ /6038851\ /uploads\ /images\ /30251i36D08BC51DE86F1D\ /jmeter_route_request1.png“ role=„button“ title=„jmeter_route_request1.png“ alt=„jmeter_route_request1.png“ /> < \ span> < \ P> < UL> < LI> In diesem Beispiel wurde die ausgewählte Anfrage erfolgreich abgeschlossen (wie durch das grüne Häkchen angezeigt)< UL class=„lia-list-style-type-circle“> < LI> Der Erfolg der übergeordneten Transaktion hat diesen Status bereits angezeigt< \ LI> < \ UL> < \ LI> < LI> Werfen Sie einen kurzen Blick auf das Feld Größe in Bytes im Sampler-Ergebnis-Tab< UL class=„lia-list-style-type-circle“> < LI> In diesem Beispiel betrug die Anforderungsgröße etwa 15 KB, was normalerweise bedeutet, dass gute Geometriedaten zurückgegeben wurden; mit anderen Worten waren die Antworten nicht „leer“ und dies ist ein weiterer Beweis dafür, dass es erfolgreich war< \ LI> < \ UL> < \ LI> < LI> Untersuchen Sie die URL der Anfrage< UL class=„lia-list-style-type-circle“> < LI> Wie bereits erwähnt wird dieser Wert der Anforderungs-URL zur Laufzeit gefüllt< \ LI> < \ UL> < \ LI> < \ UL> < UL> < LI> Klicken Sie auf den Reiter Antwortdaten und dann auf Unterreiter Antworttextkörper< UL class=„lia-list-style-type-circle“> < LI> Dies zeigt eine textuelle Ansicht der von der Anfrage zurückgegebenen Daten:< \ LI> < \ UL> < \ LI> < \ UL> < P> < span class=„lia-inline-image-display-wrapper lia-image-align-center“ image-alt=„jmeter_route_request2.png“ style=„width: 999px;“> < img src=„https:\/\ /us.v-cdn.net\ /6038851\ /uploads\ /images\ /30255i5703E7F95BDB2B5D\ /jmeter_route_request2.png“ role=„button“ title=„jmeter_route_request2.png“ alt=„jmeter_route_request2.png“ /> < \ span> < \ P > Hinweis: Die Routen-Geometrien zurückgegeben werden üblicherweise in webbasierten JavaScript-Anwendungen gerendert. Obwohl Apache JMeter ein (Test-)Client ist, rendert es diese Geometrieantworten vom Server nicht räumlich auf diese Weise.<\/STRONG><\/FONT><\/P>Testausführung<\/H1>Der Lasttest sollte auf die gleiche Weise wie ein typischer JMeter-Testplan ausgeführt werden.<\/P>Siehe das mit dem Projekt route_solver1.zip enthaltene Skript runMe.bat für ein Beispiel, wie ein Test gemäß der Empfehlung des Apache JMeter-Teams ausgeführt wird. <\/P>Das Skript runMe.bat enthält eine jmeterbin<\/EM> <\/SPAN>Variable, die auf den entsprechenden Wert für Ihre Umgebung gesetzt werden muss<\/LI>Wenn der Network Analyst-Routendienst als dediziert veröffentlicht wurde, <\/FONT>passen Sie vor dem Ausführen des Lasttests die minimalen und maximalen Instanzen entsprechend an<\/FONT>
Weitere Informationen finden Sie unter: Konfigurieren von Dienstinstanz-Einstellungen<\/A> <\/STRONG><\/FONT><\/LI><\/UL><\/LI>Der in diesem Artikel verwendete veröffentlichte Routendienst war dediziert mit maximal 4 Instanzen- Die ArcGIS Server-Komponente lief auf einem System mit 4 CPU-Kernen<\/LI><\/UL><\/LI><\/UL>
Hinweis: Es wird immer empfohlen<\/U><\/EM>, den Startzeitpunkt und die Dauer des Lasttests mit den zuständigen Personen Ihrer Organisation abzustimmen. Dies gewährleistet minimale Auswirkungen auf Benutzer und andere Kollegen, die möglicherweise ebenfalls Ihre lokale ArcGIS Enterprise-Site nutzen müssen. Zusätzlich hilft dies, Systemrauschen<\/EM> durch andere Aktivitäten und Nutzung zu vermeiden, die die Testergebnisse "verunreinigen" könnten.<\/STRONG><\/FONT><\/P>Hinweis: Aus mehreren Gründen wird dringend empfohlen, ArcGIS Online niemals einem Lasttest zu unterziehen<\/EM><\/U>.<\/STRONG><\/FONT><\/P>
JMeter-Bericht<\/H1>Durchsatzkurve<\/H2>Der automatisch generierte JMeter-Bericht kann Einblicke in den Durchsatz des Routendienstes unter Last gebenDa jede Routen-Transaktion eine Anfrage enthielt, zeigten beide Metriken (Anfrage und Transaktion) praktisch denselben Wert; dies ist angesichts des Testdesigns zu erwarten<\/LI><\/UL><\/LI>In diesem Fall lag der Spitzen-Durchsatz für die Zwei-Stopp-Routenlösungen bei etwa 15 Transaktionen pro SekundeBasierend auf der getesteten Umgebung entspricht dies etwa 54.000 Routenlösungen pro Stunde <\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Leistungskurven<\/H2>Der automatisch generierte JMeter-Bericht kann auch Einblicke in die Leistung des Routendienstes unter Last gebenDa jede Routen-Transaktion eine Anfrage enthielt, zeigten beide Metriken (Anfrage und Transaktion) praktisch denselben Wert; dies ist angesichts des Testdesigns zu erwarten<\/LI><\/UL><\/LI>Die Leistung der Routenanfragen war gut und während des gesamten Lasttests unter 1 SekundeDort, wo der Durchsatz erstmals bei 15 Transaktionen pro Sekunde seinen Höhepunkt erreichte, wurde die Antwortzeit gemessenAn diesem Punkt im Test betrug die durchschnittliche Antwortzeit etwa 333 ms oder 0,33 Sekunden<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Es kann auch hilfreich sein, die geplotteten Antwortzeiten in Bezug auf die schrittweise Last (konfigurierte Threads) zu sehenBisherige Diagramme zeigten Werte in Bezug auf Zeit<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Abschließende Gedanken<\/H1>Der Apache JMeter-Testplan in diesem Artikel stellt einen programmatischen Ansatz dar, um Last auf einen Network Analyst-Routendienst anzuwenden. Eine der Stärken dieses Tests ist, dass er einfach zu konfigurieren und zu warten ist.<\/P>Der automatisch generierte JMeter-Bericht bietet Diagramme und Zusammenfassungen, die verwendet werden können, um schnell die Leistung und Skalierbarkeit des Routendienstes zu analysieren.<\/P>Um den in diesem Artikel verwendeten Apache JMeter-Testplan herunterzuladen, siehe: route_solver1.zip<\/<\/A> <\/<\/LI>