Een Load Test maken in Apache JMeter tegen een gehoste Feature Layer Service (Middengevorderd/Geavanceerd)

AaronLopez

Waarom een Hosted Feature Layer Service testen? <\/SPAN><\/H1>Vorige Community-artikelen over prestatietesten met Apache JMeter richtten zich op het testen van Map Services via de exportfunctie. Echter, Hosted (feature) layers<\/A> zijn ook een populaire functionaliteit van ArcGIS Enterprise en worden veel gebruikt in implementaties. Bovendien zijn query's op deze lagen gebaseerd op een "herhaald" gridontwerp, wat kan helpen om een hogere mate van schaalbaarheid te bieden dan andere visualisatietechnologieën. Combineer dit met client-side rendering van de teruggegeven data en het is een win-win.<\/P>

Aangezien hosted feature services een bewezen en favoriete servicetechnologie zijn, is het logisch om feature queries onder belasting te willen testen om de schaalbaarheid uit de eerste hand te observeren.<\/SPAN><\/P>

Uitdagingen bij het testen van Hosted Feature Layer Services<\/SPAN><\/H1>In vergelijking met het testen van de export map-functie is het testen van Hosted Feature Layer Service-queries uitdagend omdat de verzoeken complexer zijn om programmatisch te realiseren. Een navigatie "pan" of een "zoom" in de webbrowser produceert een handvol verschillende query's, elk met hun eigen geometrie. Om dit gedrag te herhalen, zal de geconstrueerde load <\/SPAN>test niet slechts één verzoek bevatten, maar vele en een variërend aantal. Combineer dit met het feit dat elk queryverzoek in de transactie een unieke geometrie en veranderende maxAllowableOffset heeft (afhankelijk van de kaart schaal) en het zijn veel bewegende onderdelen om bij te houden.<\/SPAN><\/P>Hoe test je een Hosted Feature Service? <\/SPAN><\/H1>De USGS Motor Vehicle Use Roads Dataset<\/SPAN><\/H2>Het begrip van het proces in dit artikel is het meest effectief als de stappen kunnen worden gereproduceerd. Maar deze herhaalbaarheid vereist toegang tot dezelfde dataset. De ruimtelijke omvang van de gegevensbron moet ook groot genoeg zijn om degelijke testdata te genereren, maar niet zo groot dat het onhandig is om te downloaden.<\/SPAN><\/P>Voer in de Motor Vehicle Use Map: Roads<\/A> feature layer dataset op hub.arcgis.com. De 179K polyline records van USGS Roads data in WGS 1984 Web Mercator (Auxiliary_Sphere), komt neer op ongeveer 200MB wanneer gecomprimeerd. Het wordt geleverd onder de Creative Commons (CC0)<\/A> licentie.<\/SPAN><\/P>

• Weergave van Roads data vanuit ArcGIS Pro:<\/SPAN><\/LI><\/UL><\/span><\/SPAN><\/P>Grote schaalweergave met labeling ingeschakeld:<\/LI><\/UL><\/span><\/SPAN><\/P>Deze data zal worden gepubliceerd vanuit ArcGIS Pro naar een hosted feature service in ArcGIS Enterprise of direct geladen via Portal for ArcGIS.<\/SPAN><\/P>Om een service van deze data te maken, zie 

Publish hosted feature layers<\/A> in ArcGIS Enterprise<\/SPAN><\/LI><\/UL>

Genereren van testdata<\/SPAN><\/H2>Deze test vereist goede testdata om binnen de JMeter-test te gebruiken.<\/P>Om zo'n taak aan te pakken, wordt sterk aanbevolen om gebruik te maken van de zeer uitstekende Load Testing Tools<\/A>.<\/P>

Versie 1.2.2 voegt nieuwe mogelijkheden toe zoals de "Generate Query Extents" tool die een grote hulp zal zijn bij het genereren van feature service testdata.

3 primaire datasets die van belang zijn:<\/P>

• Bounding box feature classes
  • Bevat willekeurig gegenereerde interessegebieden<\/LI>
  • Één feature class voor elk aangevraagd schaalniveau<\/LI><\/UL><\/LI>
  • Query Extent feature classes
    • Bevat een (512x512) tegelraster waarop elke feature query zal worden gebaseerd<\/LI>
    • Één feature class voor elk aangevraagd schaalniveau<\/LI><\/UL><\/LI>
    • Query Extent CSV-bestanden
      • Bevat de gegenereerde testdata<\/LI>
      • Elke regel bestaat uit de dynamische componenten van een feature service aanvraag<\/LI>
      • Één bestand voor elk aangevraagd schaalniveau<\/LI><\/UL><\/LI><\/UL>

        <\/span><\/P>Laad vanuit het Catalog paneel de bbox_36112 feature class op de huidige kaart in ArcGIS ProDeze output lijkt sterk op de data van de Generate Bounding Boxes tool<\/LI><\/UL><\/LI>In dit voorbeeld zijn de willekeurig gegenereerde boxen rozeDeze gebieden vertegenwoordigen de schermresolutie van een gebruiker die data opvraagt bij de feature service<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Laad nu vanuit het Catalog paneel de query_extents_36112 feature class op de huidige kaart, maar achter (onder) de bbox_36112 data<\/LI>In dit voorbeeld zijn de query tegelraster boxen groenDeze tegels komen overeen met een gebied op de kaart waarvoor de bboxes data opvragen<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Inzoomen op de kaart kan een beter begrip geven van de relatie tussen deze twee datasets<\/LI>Zoals te zien is in onderstaande kaart, zijn sommige bboxes iets verschoven ten opzichte van elkaar, maar delen ze nog steeds een gemeenschappelijke query tegel uit het raster eronder<\/LI>De coördinaten van deze query tegels (bijv. uit de query_extent feature class) zijn wat in de CSV-bestanden komt en uiteindelijk in de JMeter load test<\/LI><\/UL><\/span><\/P>Nader bekeken onthullen de bboxes details over hun respectievelijke query samenstellingBijvoorbeeld, sommige bboxes kunnen 12 "onderliggende" tegels nodig hebben om te vervullen, andere 15 of 20<\/LI>Zoals te zien is in onderstaande kaart, vereist de bbox gemarkeerd in zwart 12 specifieke query tegels gekleurd in rood<\/LI><\/UL><\/LI><\/UL><\/span><\/P> Opmerking: Het tegelrasterontwerp van de feature service is een van haar belangrijkste sterke punten omdat het zich leent voor herhaalbaarheid. Deze herhaalbaarheid kan worden benut met caching in een deployment voor verbeterde schaalbaarheid. Dit is niet mogelijk met export map.<\/STRONG><\/FONT><\/P>Het onderzoeken van de gegenereerde CSV-bestanden zal het eindresultaat van deze transformatie onthullen<\/LI>Het bekijken van het query_extents_36112.csv bestand in een teksteditor zou iets vergelijkbaars moeten tonen als het volgendeAfhankelijk van de release van Load Test Tools kunnen de CSV-bestanden gesorteerd zijn op de operationid kolom<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Aan afhankelijkheid van de release van Load Testing Tools kan de regel wel of niet gegroepeerd zijn op basis van de operationid kolom<\/LI>Het begrip van operationid is in dit geval een belangrijk testconcept aangezien elke operatie een navigatieactie vertegenwoordigt (bijv. een pan of zoom)<\/LI>Vanuit JMeter's perspectief is een operatie hetzelfde als een transactieAlle regels met dezelfde operationid worden feature service query aanvraag geometrieën onder dezelfde transaction controller<\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> kleur="#FF0000">Opmerking: JSR223 Samplers die Groovy gebruiken worden over het algemeen snel uitgevoerd en voegen zeer weinig overhead toe aan de test

        

Operation Loop en Parameter Populatie

Met een gekozen operation id wordt de focus de loop-logica waar de test het aantal feature services queries zal opzoeken die de transactie vormen. Vanaf daar zal het een derde set JSR223 Samplers gebruiken om de request parameters te vullen die geassocieerd zijn met de eerder geselecteerde operation id bij elke iteratie in de loop. 

• Er is één JSR223 Sampler voor elke kaart schaal die de geassocieerde JMeter variabelen vult op basis van de operation id en iteratiewaarde
  • Deze items worden dan key/value paren die opgepikt worden door de HTTP Request
  • De iteratiewaarden worden bijgehouden door een Counter Config Element
  • Deze JSR223 Samplers hoeven niet bewerkt te worden om de test uit te voeren
• Elke Loop Controller, Counter, JSR223 Sampler en HTTP Request objecten zijn allemaal geplaatst binnen een corresponderende Transaction Controller om de items logisch te scheiden voor elke kaart schaal

HTTP Request

In wezen bestaat alle bovenstaande testlogica alleen voor dit onderdeel van de test. Hier kan het JMeter HTTP Request object de JMeter variabelen lezen voor specifieke key/value parameters die zijn gevuld door de JSR223 Sampler direct ervoor.

Aangezien deze aanpak zeer programmatisch is, is er slechts één HTTP Request per kaart schaal! Zo'n ontwerp bevordert onderhoudbaarheid.

Opmerking: Deze testaanpak zou ook werken voor traditionele, niet-gehoste feature layer services. Echter, deze feature services hebben niet dezelfde request parameter optimalisaties als hosted services zoals maxAllowableOffset en quantizationParameters. Deze opties zouden gewoon verwijderd moeten worden uit de HTTP Request.

De Thread Group Configuratie

Het JMeter Test Plan is momenteel geconfigureerd voor een relatief korte test van 10 minuten. Over het algemeen presteren hosted feature services goed, dus er zal veel throughput plaatsvinden binnen elke stap (1 minuut per stap) evenals van de test in het geheel.

• Verschillende omgevingen en data kunnen een alternatieve instelling vereisen om de gewenste testresultaten te bereiken, pas aan indien nodig

Validatie van het Test Plan

Als beste praktijk is het altijd een goed idee om de terugkomende resultaten te valideren voordat je de daadwerkelijke load test uitvoert.

• Gebruik de View Results Tree listener om te helpen bij de validatie
  • Het Test Plan bevat een View Results Tree Listener maar deze is standaard uitgeschakeld
    • Zet hem aan om de resultaten te bekijken
• Start vanuit de GUI de test

Transacties 

• Selecteer één van de "HFS" Transacties
  • De resultaten zouden er als volgt uit moeten zien:

• In dit voorbeeld zijn de bovengenoemde transacties: HFS (mapscale: 72224), HFS (mapscale: 36112), en HFS (mapscale: 144448) allemaal succesvol afgerond
  • Het Sampler resultaat geeft wat meer details weer
    • Hoewel elke Transactie één HTTP request per feature query extent stuurde, telt de JMeter test de Sampler als onderdeel van de operatie
      • De JSR223 Samplers voegen zeer weinig overhead toe aan de Transactie hoewel ze wel het aantal samples verdubbelen, dit is slechts een detail om bewust van te zijn
• Kijk snel naar de Size in bytes
  • In dit voorbeeld was de Transactie Grootte bijna 65KB wat suggereert dat er data werd teruggegeven en dat de responses niet "leeg" waren

Requests

• Vouw één van de "HFS" Transacties uit
• Selecteer één van de https requests
  • De resultaten zouden er als volgt uit moeten zien:

• In dit voorbeeld is het select request succesvol afgerond
• Kijk snel naar de Size in bytes
  • In dit voorbeeld was de Request Grootte ongeveer 5KB wat suggereert dat er data werd teruggegeven en dat de responses niet "leeg" waren (bijv. 1500 bytes)
• De ContentType is ook belangrijk
  • Volgens de parameters in het Test Plan is het gevraagde formaat pbf wat application/x-protobuf teruggeeft
    • Het aanvragen van protocol buffers is een best practice omdat het payload optimaliseert
      • Het resulterende formaat is binair en kan niet gemakkelijk bekeken worden zonder extra hulp die niet behandeld wordt in dit artikel

Opmerking: Feature services (inclusief hosted feature services) worden gerenderd op de client (niet op de server zoals export map). Hoewel Apache JMeter een (test) client is, rendert het niet server responses via JavaScript zoals een webbrowser.

Testuitvoering

De load test moet op dezelfde manier uitgevoerd worden als een typisch JMeter Test Plan.

Zie het runMe.bat script inbegrepen bij het roads_hfs1.zip  project voor een voorbeeld hoe je een test uitvoert zoals aanbevolen door het Apache JMeter team. 

• Het runMe.bat script bevat een jmeterbin variabele die ingesteld moet worden op de juiste waarde voor jouw omgeving

Opmerking: Het wordt altijd aanbevolen om het starttijdstip en duur van de load test af te stemmen met het juiste personeel. Dit zorgt voor minimale impact op gebruikers en andere collega's die mogelijk ook gebruik moeten maken van de ArcGIS Enterprise Site. Daarnaast helpt dit voorkomen dat systeemruis van andere activiteiten en gebruik "vervuiling" veroorzaakt in de testresultaten.

JMeter Rapport

Throughput Curves

• Het automatisch gegenereerde JMeter Rapport kan inzicht geven in de throughput van de HFS transacties onder load
• Niet-HFS Transacties zijn handmatig eruit gefilterd
• In dit geval was de piekdoorvoer voor HFS operaties ongeveer 16,5 transacties/seconde
  • Aangezien er 3 HFS transacties waren, komt dit neer op bijna 50 transacties/seconde (of 178.200 transacties/uur)

Opmerking: Elk van de HFS Transacties zal natuurlijk een vergelijkbare throughput hebben aangezien hun respectievelijke uitvoering in de test hetzelfde gewogen was.

Performance Curves

• Het automatisch gegenereerde JMeter Rapport kan inzicht geven in de performance van HFS transacties onder load
  • Niet-HFS Transacties zijn handmatig eruit gefilterd
in dit geval waren HFS-transacties voor alle schalen sub-seconde (minder dan 1 seconde)
• Zelfs tegen het einde van de test, onder de zwaarste belasting, was de gemiddelde reactietijd minder dan 225 ms of 0,225 seconden

Laatste gedachten

Er zijn andere manieren om een hosted feature layer service queries te testen, zoals via vastgelegde verkeer van een webbrowser tijdens interactie met het eindpunt of de applicatie. Dit zou een lijst van de service-URL's opleveren die vertaald kunnen worden naar een test. Echter, een programmatische benadering zoals die in dit artikel wordt beschreven, biedt een strategie om een groot ruimtelijk gebied van de service te testen dat veel meer extents beslaat dan praktisch mogelijk is met de vastgelegde verkeer-benadering.

De programmatische benadering is ook gemakkelijker te onderhouden omdat de omvang van het Test Plan veel kleiner is. Om dit in perspectief te plaatsen: de JMeter-test in dit artikel bevatte slechts 3 HTTP-verzoeken (één voor elke kaart schaal). 

• Om het Apache JMeter Test Plan te downloaden dat in dit artikel is gebruikt, zie: roads_hfs1.zip
• Om de Natural Earth subset van data te downloaden die in dit artikel is gebruikt, zie: Motor Vehicle Use Map: Roads (Feature Layer) 

 

 

 

Apache JMeter uitgebracht onder de Apache License 2.0. Apache, Apache JMeter, JMeter, de Apache veer en het Apache JMeter-logo zijn handelsmerken van de Apache Software Foundation.

AaronLopez

Hi @StevenBeothy 

I think that test plan is valid and a good programmatic way to get a performance profile from each of the layers

However, there are a few items worth mentioning:

• My roads_hfs test requested * for the outFields
  • This is fine but can be considered aggressive, especially if the tables are "wide" (e.g., 50 or more attributes)
  • In that case, I would consider maybe asking for a few specific attributes (e.g., OBJECTID plus one or two others)
  • But, that assumes the requested attributes exist in all the layers
    • This is why using * is so easy
• My roads_hfs test was build around using hosted feature service queries (e.g., where resultType=tile)
  • I am a huge fan of the feature tiles and their data structure lends itself to efficient querying (repeatable extents for better caching, more predictable quantization tolerances for each of the layers)
  • A resultType of say standard would be similar but the test logic would be different (and in my opinion, more complex)
    
    • Additionally, requests with resultType=standard can ask for varying numbers of records being returned (through the use of the resultRecordCount and resultOffset parameters)
      • This adds variance and test complexity...which again is why I like testing with resultType=tile

To reiterate, I think your approach is good and resultType=tile style tests are a great way to consume a feature service.
I bring up these other items to give my opinion and perspective on what your test is doing and how its asking for the data...as well as the potential test logic impacts when asking for feature data when the resultType is not tile.

Hope that helps.