Network Analyst Route
In eenvoudige bewoordingen wordt de Network Analyst route-oplosser gebruikt om de snelste manier te vinden om van de ene plaats naar de andere te komen. Dit afgelegde pad kan alleen een start- en eindlocatie omvatten, maar kan optioneel stoppen bij meerdere locaties terwijl ook wordt gevraagd om stapsgewijze aanwijzingen voor elke route in de oplossing te genereren.
Opmerking: Routefunctionaliteit is beschikbaar met een Network Analyst-licentie.
Load Testing van een Network Analyst Route Service
Network Analyst zit boordevol mogelijkheden en functies voor routeoplossingen. Dergelijke oplossingen kunnen worden uitgevoerd via ArcGIS Pro, maar worden vaak geconsumeerd via een ArcGIS-service. Omdat het toonaangevende technologie biedt voor routeoplossingen, is het logisch om je lokaal draaiende (route) oplosserservice load te testen om het schaalbaarheidspotentieel te zien.
Er zijn verschillende soorten analyses die door de Network Analyst-extensie worden aangeboden, dit artikel gebruikt routes omdat ze heel gemakkelijk te gebruiken zijn... de enige vereiste invoer zijn ten minste twee geldige stopplaatsen. Deze eigenschap maakt het een goede keuze om te demonstreren hoe data gegenereerd kan worden en gebruikt kan worden in een loadtest tegen een routeservice.
Opmerking: De walkthrough in dit artikel gebruikte ArcGIS Pro 2.9 met Network Analyst-services die draaiden in een ArcGIS Enterprise 10.9-implementatie.
Hoe test je een Network Analyst Route Service?
Network Analyst ArcGIS Pro Tutorial Data
Het begrip van de processen in dit artikel is het meest effectief als de stappen gevolgd kunnen worden met dezelfde data. Voor zo'n taak heeft het Network Analyst-team een geweldige dataset beschikbaar gesteld.
Er is een tutorial te vinden op arcgis.com genaamd Network Analyst ArcGIS Pro Tutorial Data. Gecomprimeerd is het ongeveer 132MB en bestaat uit Network Analyst-data voor verschillende steden: San Diego, Parijs en San Francisco. Het geografisch coördinatensysteem is: WGS 1984 (WKID: 4326). De data is openbaar toegankelijk.
Opmerking: De voorbeelden in dit artikel richten zich op de San Diego-dataset.
- Weergave van de San Diego Streets-data vanuit ArcGIS Pro (met Topographic Basemap):
- De lagen Streets, Walking_Pathways of Network Dataset (NewSanDiego_ND) hoeven niet ingeschakeld te zijn om gebruik te maken van de Network Analyst-mogelijkheden
- In het bovenstaande voorbeeld zijn ze ingeschakeld als referentiepunt voor de straten van San Diego
- Dit artikel zal niet de details behandelen over het maken, configureren of publiceren van een netwerkdataset in ArcGIS Enterprise. Voor informatie over dergelijke taken, zie:
Opmerking: De route-oplosservoorbeelden in dit artikel gebruiken een kaartservice (met netwerk-analysemogelijkheid) in plaats van een geoprocessingservice. De kaartservice gebruikt synchrone uitvoering.
Testgegevensgeneratie
Deze testinspanning vereist geldige stopplaatsen om binnen de JMeter-test te gebruiken.
Net als bij andere JMeter-artikelen op Community hebben we goede testdata nodig om de meeste waarde uit de resultaten te halen. En zoals eerder maken de Load Testing Tools dit werk snel gedaan. Er is zelfs een specifieke tool voor het creëren van routedata.
Versie 1.3.0 voegt enkele mooie verbeteringen toe aan de "Generate Data (Solve Route)" tool.
De tools beschikbaar maken vanuit ArcGIS Pro
Zodra het load-testing-tools project naar je machine is gedownload, plaats je de uitgepakte map in een directory die toegankelijk is of gemaakt wordt door ArcGIS Pro. Als je al een eerdere versie van de Load Testing Tools hebt geïnstalleerd, kan deze bijgewerkte versie ernaast geplaatst worden (hoewel met een andere mapnaam) of volledig de vorige versie vervangen.
Bijvoorbeeld:
- Plaats de map load-testing-tools in C:\Users\[gebruikersnaam]\Documents\ArcGIS
- Gebruik Add Folder Connection vanuit Catalogus in ArcGIS Pro om de inhoud van deze directory weer te geven:
De "Generate Data (Solve Route)" tool kan testdata creëren vanuit de (kaart)service, een lokale kopie van de data of de data binnen een enterprise-geodatabase. Voor dit voorbeeld kan elke data in WGS 1984 (WKID: 4326) met een interessegebied rond San Diego gebruikt worden.
Start de Generate Data (Solve Route) Tool
- Het starten van de Generate Data (Solve Route) tool zou een interface moeten tonen die lijkt op het volgende:
- In zijn eenvoudigste vorm hoeft alleen het pad naar het csv-bestand, dat de stopplaatsen zal bevatten, gespecificeerd te worden
- Echter, terwijl we willekeurige punten willen genereren om als stops te gebruiken, willen we voorkomen dat ze in baaien, meren of oceaan worden gemaakt
- Hier komt de optionele parameter Constraining Polygon om de hoek kijken
- Dit invoerveld kan gebruikt worden om naar een datalaag te verwijzen die ruimtelijk beperkt waar punten gegenereerd mogen worden
- In werkelijkheid zullen we alle standaardwaarden aanpassen
- Weergave van het polygoon (in roze) dat het interessegebied van de San Diego stratenlaag in ArcGIS Pro omlijnt:
Opmerking: Dit polygoon is handmatig gemaakt en is niet inbegrepen bij de San Diego-dataset
- Om het gebruikte shapefile SanDiegoPolygon in dit artikel te downloaden zie: SanDiegoPolygon.zip
Opmerking: Vanuit testperspectief hoeft het polygoon niet elk segment van de stratenlaag te bevatten.
De invoerparameters van Generate Data (Solve Route) Tool
- PAS AANTAL TESTS AAN naar:
- PAS STOPS PER TEST AAN naar:
- Zet Constraining Polygon op:
- Zet Output op een bestandslocatie waar resultaten geschreven zullen worden:
- C:\Users\[gebruikersnaam]\Documents\ArcGIS\Projects\NetworkAnalystMap1\sandiegostops1.csv
- Klik op Uitvoeren om de tool uit te voeren
- Het bekijken van het CSV-bestand zal de gegenereerde stopgegevens
- Deze gegevens worden direct gebruikt in de Apache JMeter-test als invoer
- Het bekijken van het bestand in een teksteditor zou iets vergelijkbaars moeten tonen als het volgende:
- De functies van de route solver zijn verbazingwekkend uitgebreid en kunnen andere ruimtelijke gegevens accepteren, bijvoorbeeld:
- Barrières, Polyline Barrières en Polygon Barrières zijn andere invoer die kan worden doorgegeven aan een aanvraagparameter
- De generatie van deze andere invoer voor route solver-aanvragen wordt niet behandeld in dit artikel
Ruimtelijk visualiseren van de gegenereerde punten
De gegenereerde punten die worden gebruikt voor de stops in de aanvragen kunnen worden toegevoegd aan het ArcGIS Pro-project om hun locatie ruimtelijk te bekijken.
- Gebruik vanuit ArcGIS Pro Catalogus om de bestand-geodatabase binnen het project te vinden en te openen
- Zoek de feature class random_pts
- Voeg de feature class toe aan de huidige kaart:
Het Route Solver Testplan
- Om het Apache JMeter Testplan te downloaden dat in dit artikel wordt gebruikt, zie: route_solver1.zip
- Het openen van het Testplan in Apache JMeter zou er ongeveer als volgt uit moeten zien:
- Pas de door de gebruiker gedefinieerde variabelen aan om bij uw omgeving te passen
Opmerking: De gebruikte Apache JMeter-versie voor dit artikel was 5.4.3 (deze versie biedt kritieke beveiligingsupdates voor Apache Log4j2). Het wordt sterk aanbevolen dat alle Apache JMeter-implementaties op de nieuwste versie draaien.
HTTP-aanvraag
De route solve-test is eenvoudig en vrij rechttoe rechtaan. Alle testlogica is te vinden binnen één JMeter HTTP Request-object. Volgens de teststijl die in eerdere artikelen is gebruikt, wordt dit aanvraagitem geplaatst binnen een Transaction Controller.
De sleutel-/waardeparen voor de aanvraag in deze JMeter-test zijn gebaseerd op twee factoren:
- De functionaliteit beschikbaar in de gepubliceerde Network Analyst-service (en onderliggende data)
- De waarden in deze test zijn rechtstreeks genomen van de standaardwaarden die worden gebruikt vanaf het REST-eindpunt van de gepubliceerde San Diego-service, bijvoorbeeld:
- De versie van ArcGIS Enterprise (ArcGIS Server)
- Sommige versies voegen nieuwe mogelijkheden toe
- Deze test is gebaseerd op de gepubliceerde service van de San Diego-dataset en ArcGIS Enterprise 10.9
Verschillende netwerkdatasets kunnen verschillende aanvraagparameteropties beschikbaar of gevuld zijn, standaard. Sommige parameters, indien ingeschakeld (zoals returnDirections), zullen de solver vertellen meer informatie terug te geven. Dit vraagt op zijn beurt de service om meer werk te doen wat de responstijd van de aanvraag zal verhogen.
Opmerking: De weergave van de HTTP-aanvraag vanuit de inhoudsopgave (linkerkant van het Testplan) zal verschijnen als een mix van JMeter-variabelen en strings. Dit is opzettelijk. Deze waarden worden tijdens afspelen ingevuld (in het View Results Tree-object en ruwe resultatenbestand).
Configuratie van Thread Group
Het JMeter Testplan is geconfigureerd voor een loadtest van 20 minuten. Met deze testvoorbeeld die twee stops per routeaanvraag gebruikt, zou de solver goed moeten presteren en een goede hoeveelheid monsters (bijv. reacties van de server) voor elke stap moeten teruggeven.
- Verschillende omgevingen en data kunnen een alternatieve instelling vereisen om het gewenste testresultaat te bereiken, pas indien nodig de testthread-instellingen aan
Validatie van het Testplan
Als beste praktijk is het altijd een goed idee om de resultaten die terugkomen binnen de JMeter GUI te valideren voordat u de daadwerkelijke loadtest vanaf de opdrachtregel uitvoert.
- Gebruik de View Results Tree-luisteraar om te helpen bij de validatie
- Het Testplan voor dit artikel bevat een View Results Tree Listener maar deze is uitgeschakeld
- Zet deze aan om de resultaten te bekijken wanneer de test vanuit de GUI wordt afgespeeld
- Start vanuit de GUI de test
- Laat de test ongeveer 20 seconden draaien
Transacties
- Selecteer een van de "Route" Transacties
- Het View Results Tree-gedeelte zou er ongeveer als volgt uit moeten zien:
- In dit voorbeeld zijn alle transacties succesvol afgerondSoms kunnen bij het stoppen van het afspelen, de laatste transacties in het View Results Tree falen omdat ze "midden in een aanvraag" werden gestopt; dit kan veilig worden genegeerd
Aanvragen
- Bewerk een van de "Route" Transacties
- Selecteer daarin het HTTPS-verzoek
- De resultaten zouden er ongeveer als volgt uit moeten zien:
- In dit voorbeeld is het geselecteerde verzoek succesvol afgerond (aangegeven door het groene vinkje)Het succes van het bovenliggende Transaction gaf deze status al aan
Kijk snel naar het veld Grootte in bytes op het tabblad Sampler-resultaat- In dit voorbeeld was de grootte van het verzoek ongeveer 15KB wat meestal betekent dat goede geometriegegevens werden teruggegeven; met andere woorden, de reacties waren niet "leeg" en dit is meer bewijs dat het succesvol was
Kijk naar de URL van het verzoek
- Zoals eerder vermeld, wordt deze waarde van de aanvraag-URL tijdens runtime ingevuld
- Klik op het tabblad Response data en sub-tab Response Body
- Dit toont een tekstuele weergave van de gegevens die door het verzoek zijn teruggegeven:
Opmerking: De routegeometrieën worden meestal weergegeven in op webbrowsers gebaseerde JavaScript-toepassingen. Hoewel Apache JMeter een (test)client is, rendert het deze geometrie-antwoorden van de server niet ruimtelijk op die manier.<\/STRONG><\/FONT><\/P>Testuitvoering<\/H1>De loadtest moet op dezelfde manier worden uitgevoerd als een typisch JMeter Test Plan.<\/P>Zie het runMe.bat-script dat is meegeleverd met het route_solver1.zip-project voor een voorbeeld van hoe een test wordt uitgevoerd zoals aanbevolen door het Apache JMeter-team. <\/P>Het runMe.bat-script bevat een jmeterbin<\/EM> <\/SPAN>variabele die moet worden ingesteld op de juiste waarde voor uw omgeving<\/LI>Als de Network Analyst route service als dedicated is gepubliceerd, <\/FONT>pas dan het minimum en maximum aantal instanties dienovereenkomstig aan voordat u de loadtest uitvoert<\/FONT>
Voor meer informatie zie: Configure service instance settings<\/A> <\/STRONG><\/FONT><\/LI><\/UL><\/LI>De gepubliceerde route service die in dit artikel wordt gebruikt, was dedicated met het maximum aantal instanties ingesteld op 4
JMeter-rapport<\/H1>Doorvoercurve<\/H2>Het automatisch gegenereerde JMeter-rapport kan inzicht geven in de doorvoer van de route service onder belastingAangezien elke Route Transaction één verzoek bevatte, toonden beide statistieken (verzoek en transactie) vrijwel dezelfde waarde; dit is te verwachten gezien het ontwerp van de test<\/LI><\/UL><\/LI>In dit geval was de piekdoorvoer voor de twee-stop route-oplossingen ongeveer 15 transacties per secondeGezien de geteste omgeving komt dit neer op ongeveer 54.000 route-oplossingen per uur <\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Prestatiecurves<\/H2>Het automatisch gegenereerde JMeter-rapport kan ook inzicht geven in de prestaties van de route service onder belastingAangezien elke Route Transaction één verzoek bevatte, toonden beide statistieken (verzoek en transactie) vrijwel dezelfde waarde; dit is te verwachten gezien het ontwerp van de test<\/LI><\/UL><\/LI>De prestaties van de routeverzoeken waren goed en bleven gedurende de hele loadtest onder 1 secondeWaar de doorvoer voor het eerst piekte bij 15 transacties per seconde, werd ook de responstijd gemetenOp dat moment in de test was de gemiddelde responstijd ongeveer 333 ms of 0,33 seconden<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Het kan ook nuttig zijn om de uitgezette responstijden te zien ten opzichte van de stapbelasting (geconfigureerde threads)Eerdere grafieken toonden waarden ten opzichte van tijd<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>Slotgedachten<\/H1>Het Apache JMeter Test Plan in dit artikel vertegenwoordigt een programmatische benadering voor het toepassen van belasting op een Network Analyst route service. Een van de sterke punten van deze test is dat het gemakkelijk te configureren en te onderhouden is.<\/P>Het automatisch gegenereerde JMeter-rapport biedt grafieken en samenvattingen die snel kunnen worden gebruikt om de prestaties en schaalbaarheid van de route service te analyseren.<\/P>Om het Apache JMeter Test Plan te downloaden dat in dit artikel wordt gebruikt, zie: route_solver1.zip<\/<\/A> <\/<\/LI>
