nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Gebruik van Public Domain Data om een ArcGIS Enterprise Map Service te benchmarken (Gemiddeld niveau)

AaronLopez

Het kiezen van een Capability van ArcGIS Enterprise om te benchmarken

Als het fundamentele softwaresysteem voor GIS, voert ArcGIS Enterprise veel taken uit zoals mapping en visualisatie, analytics. Vanuit dit brede scala aan capabilities en functies is er geen enkele test die al zijn mogelijkheden kan vertegenwoordigen.

Echter, als één functie zou worden gebruikt als benchmark voor het testen van een ArcGIS Enterprise-implementatie, kan een sterk argument worden gemaakt voor de map service exportfunctie. Export map kan gemakkelijk en programmatisch worden aangeroepen in een Apache JMeter Test Plan door de ruimtelijke extents van de verzoeken te variëren vanuit CSV-gegevensbestanden over verschillende kaartschalen. Dit vertaalt zich naar slechts één verzoek per kaart schaaltransactie wat helpt om de test eenvoudig en onderhoudbaar te houden. Gecombineerd met het feit dat de exportfunctie beschikbaar is sinds versie 9.3, maakt dit een bewezen en betrouwbare operatie om te benchmarken.

Wat is een Benchmark van een Map Service?

GIS-testers en beheerders krijgen vaak de taak om de verschillen in doorvoer tussen twee systemen of hetzelfde systeem na een vorm van omgevingswijziging te begrijpen. In dergelijke scenario's is een benchmark het proces van het uitvoeren van een load test die dient als standaard waarmee meerdere dingen met elkaar kunnen worden vergeleken.

Met betrekking tot GIS zou deze load test een Apache JMeter Test Plan zijn dat een step load test uitvoert tegen een ArcGIS Enterprise map service om het hoogste doorvoertarief (transacties/sec of verzoeken/sec) te begrijpen dat kan worden bereikt vanuit de implementatie gegeven een bepaalde staat of configuratie. Dit tarief staat ook bekend als de piekdoorvoer. Bij piekdoorvoer is het ook cruciaal om de prestaties (transactie- of verzoek-responstijd) te meten.

Benchmark Dataset

Elke dataset kan worden gebruikt voor een benchmark zolang deze constant wordt gehouden waarbij wijzigingen zoals toevoegingen, updates, verwijderingen en versies van feature classes niet worden aangebracht. Deze consistentie helpt bij het creëren van een betrouwbare "standaard" omdat het een niet-bewegend doelwit is. De testgegevens kunnen privé (bijv. propriëtair) of openbaar domein zijn.

Wat is Public Domain Data?

Over het algemeen zou public domain data elk raster- of vector dataset zijn dat gratis te downloaden en te gebruiken is. Er zijn veel public domain datasets beschikbaar (en mogelijk verschillende licenties die ze definiëren). De data die in dit artikel wordt gebruikt is Gemaakt met Natural Earth en beschikbaar gesteld via de Creative Commons (CC0)-licentie.

Waarom Public Domain Data gebruiken?

Een van de kenmerken die een goede benchmark maken, is het opzetten van een test zodat anderen dezelfde test kunnen herhalen die jij hebt gedaan. Public domain data is hierin een goede keuze omdat het een teststandaard bevordert en een betrouwbare meetlat biedt voor prestaties en schaalbaarheid.

SampleWorldCities vs Natural Earth

Hoewel de opname van SampleWorldCities in ArcGIS Server via de installatie helpt om de dataset alomtegenwoordig te maken en goed voor testvoorbeelden en walkthroughs, maakt de extreem kleine omvang het niet ideaal voor benchmarking van een map service.

De Natural Earth datasets bieden daarentegen redelijk wat kaartdetail (op kleinere schalen) die de hele wereld beslaan. Bovendien kan dit worden bereikt met een gemakkelijk hanteerbare schijfruimte, wat het praktischer maakt om te delen, downloaden en gebruiken.

De Benchmark Natural Earth Dataset

Download hier de benchmark dataset
- De data is een subset van de Natural_Earth_quick_start.zip en bevat een aangepaste MXD voor ArcMap 10.8.1 en ArcGIS Pro 2.8 project.
  - Beide kunnen worden gebruikt om een map service te publiceren naar ArcGIS Enterprise.
De Natural Earth subset van data zou er ongeveer zo uit moeten zien wanneer geopend in ArcGIS Pro (of ArcMap)

Implementatie Architectuur

Architectuur is belangrijke detail van een benchmark. De volgende zijn allemaal belangrijke componenten van benchmark architectuur die invloed hebben op de test:

Bestaat er een Web Adaptor?
Was authenticatie betrokken of was de service beschikbaar voor iedereen
- Portal for ArcGIS authenticatie
- ArcGIS Server token authenticatie
- Beschikbaar voor iedereen
Hoeveel machines namen deel aan de ArcGIS Site?
Processor details
- Processor model en architectuur
- Aantal CPU cores voor elke server (inclusief het testclient werkstation)
- Fysiek, virtueel of cloud
Details over fysiek geheugen
- Totaal systeemgeheugen
Netwerksnelheid
ArcGIS Enterprise versie
Besturingssysteem versie

Opmerking: Het wordt aanbevolen om aantekeningen te maken van de implementatie architectuur details. Het opslaan van deze informatie samen met de testresultaten kan helpen om juiste context en betekenis te geven aan de analyse of conclusies.

De resultaten vermeld voor deze benchmarktest werden uitgevoerd tegen de volgende omgeving architectuur:

ArcGIS Server (10.9 Final)
- Dell PowerEdge R640
  - SPECint_rate_base2006
  - HyperThreading uitgeschakeld
  - 128GB RAM
- Windows Server 2019
- 10G netwerk
ArcGIS Web Adaptor (10.9 Final)
- Dell PowerEdge R440
  - SPECint_base2006
  - HyperThreading uitgeschakeld
  - 64GB RAM
- Windows Server 2019
- 10G netwerk

Test Client
- Apache JMeter 5.4.1
- Dell PowerEdge R640
- SPECint_rate_base2006
  - 6 virtuele CPU's
  - 16GB RAM
- Windows Server 2019
- 10G netwerk

als de implementatie meerdere servers heeft die samen de ArcGIS Enterprise Site vormen. In beide gevallen, remote of lokaal, is de locatie van de gegevensbron ook een belangrijk detail van de testomgeving dat genoteerd moet worden.<\/SPAN><\/P>

Opmerking: Het wordt aanbevolen om de locatie van de gegevensbron te noteren. Het opslaan van deze informatie met de testresultaten kan helpen om de juiste context en betekenis aan de analyse of conclusies te geven.<\/STRONG><\/FONT><\/P>Servicetype en aantal instanties<\/FONT><\/H2>Voor de meest gebruikte ArcGIS-kaartservices in een Site wordt aanbevolen om de resource te publiceren als een Dedicated instantie in plaats van Shared. Hoewel beide typen kunnen schalen om de beschikbare hardware volledig te benutten, heeft een Dedicated service-instantie achter de schermen middelen die eraan zijn toegewezen, wat het een ideale keuze maakt voor een benchmarktest.<\/FONT><\/P>Voor voorspelbare prestaties wordt aanbevolen om het Minimum en Maximum aantal instanties voor het type Dedicated instantie gelijk te stellen aan het aantal CPU-kernen van de ArcGIS Server-machine.<\/FONT><\/P>Opmerking: Het wordt aanbevolen om het servicetype en het aantal instanties te noteren. Het opslaan van deze informatie met de testresultaten kan helpen om de juiste context en betekenis aan de analyse of conclusies te geven.<\/STRONG><\/FONT><\/P>Zijn de aanvraagopties in een Benchmark Test belangrijk?<\/H2>Absoluut! Het gebruik van een gemeenschappelijke dataset en de exportmapfunctie is niet voldoende om een betrouwbare benchmark vast te stellen. De exportbewerking is uiterst veelzijdig, maar door deze flexibiliteit kan een afbeelding worden gegenereerd via verschillende invoeropties.<\/P>Een loadtest die consequent verzoeken naar de kaartservice stuurt, is belangrijk voor het vaststellen van een betrouwbare benchmark. Kan de test een BMP-afbeeldingsformaat aanvragen in plaats van PNG of vragen om gegevens in een andere ruimtelijke referentie dan de standaard 4326? Ja, maar het wijzigen van dergelijke opties kan invloed hebben op de prestaties en schaalbaarheid van de test, dus het wordt aanbevolen om deze Test Plan-instellingen ongewijzigd te laten.<\/P>Het Map Service Benchmark Test Plan <\/H1>Om het Apache JMeter Test Plan te downloaden dat in dit artikel wordt gebruikt, zie: <\/SPAN>naturalearth1.zip<\/A> <\/STRONG>

Dit Test Plan is grotendeels gebaseerd op het SampleWorldCities-testproject uit

een eerder artikel<\/A><\/LI><\/UL><\/LI><\/UL>
Het downloaden en openen van het Test Plan in Apache JMeter zou er ongeveer als volgt uit moeten zien:
Pas de User Defined Variables aan zodat ze bij uw omgeving passen<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P> De samenstelling van het verzoek (één voor elk van de 5 geteste kaartschalen) zou er ongeveer als volgt uit moeten zien:<\/LI><\/UL><\/span><\/P>

De Thread Group Configuratie<\/H2>De Thread Group definieert de stapbelastingkenmerken van de test en speelt een belangrijke rol. Voor een exportmap heeft het maximale aantal Threads voor de test een nauwe relatie met het maximale aantal ArcGIS Server CPU-kernen (en vergelijkbaar, het maximale aantal service-instanties). Het configureren van testthreads die het aantal kernen overschrijden helpt ervoor te zorgen dat er voldoende druk wordt uitgeoefend om de server-CPU-middelen volledig te benutten. Vanaf daar zou piekdoorvoer moeten worden waargenomen, wat een primair doel is van een benchmarktest.<\/P>Opmerking: Niet alle geteste datasets zullen respectievelijk laten zien dat de service volledig gebruikmaakt van de CPU van de ArcGIS Server-laag. In dergelijke gevallen is aanvullende probleemoplossing nodig om te begrijpen waar de bottleneck zit die de schaalbaarheid van de gegeven workflow beperkt.<\/STRONG><\/FONT><\/P>Als vuistregel configureer je de maximale stapbelasting 25% -- 60% hoger dan het aantal server-CPU-kernenZoals hieronder te zien is, is het Test Plan geconfigureerd om 1 uur te draaien en een maximale stapbelasting van 40 gelijktijdige testthreads te bereikenDit zou beginnen met 1 testthread en elke 90 seconden een extra thread toevoegen<\/LI>Deze benchmark is ontworpen om een ArcGIS Server-implementatie te testen die draait op 24 fysieke CPU-kernen <\/LI>Pas dit dienovereenkomstig aan, niet elke ArcGIS Server draait op 24 fysieke kernen en de maximale stapwaarden kunnen te hoog zijn voor uw implementatie<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL><\/span><\/P>Opmerking: Het wordt aanbevolen om details over de stapbelastingconfiguratie te noteren. Het opslaan van deze informatie met de testresultaten kan helpen om juiste context en betekenis aan analyse of conclusies te geven.<\/STRONG><\/FONT><\/P>Uitvoering Benchmark Test<\/H1>De benchmark moet op dezelfde manier worden uitgevoerd als een typisch JMeter Test Plan.
Zie het runMe.bat-script dat bij het naturalearth1.zip-project is inbegrepen voor een voorbeeld hoe je een test uitvoert zoals aanbevolen door het Apache JMeter-team.
Opmerking: Het wordt altijd aanbevolen om het starttijdstip en duur van de loadtest 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. Bovendien helpt dit voorkomen dat systeemruis door andere activiteiten en gebruik "vervuiling" veroorzaakt in de testresultaten.
Resultaten en Analyse<\ /H1 > Zodra de loadtest is voltooid , instrueert runME.bat Apache JMeter automatisch om een rapport te genereren om te helpen bij de analyse van de resultaten . <\ / P > Er kunnen hele artikelen en internetbronnen exclusief gewijd zijn aan het analyseren van componenten uit resultaten van loadtests . Dus , in belang van eenvoud , richten we ons op aanvraagdoorvoer (aanvragen / sec)<\ / STRONG > en aanvraagprestaties (seconden) <\ / STRONG > metriek uit het rapport . <\ / P > De onderstaande diagrammen illustreren ideale trends van deze twee items in tijd tijdens de test . <\ / P >< H2 id = "toc-hId-1380701144">De Ideale Doorvoercurve<\ / H2 >< img src = "https://us.v-cdn.net/6038851/uploads/images/17248iF22584F5C377D6E1/theoretical_throughput_curve.png" role = "button" title = "theoretical_throughput_curve.png" alt = "theoretical_throughput_curve.png" \/ ><\ / span ><\ / P > <\ / P > Idealiter zal de doorvoercurve dezelfde vorm hebben als bovenstaande oranje lijn . Het punt waar deze curve piekt en begint af te vlakken geeft aan dat het systeem zijn hoogste doorvoerniveau heeft bereikt (door hardware- of softwarebottleneck) . Dit gebied op grafiek waar curve buigt wordt aangeduid als knie<\ / EM > en hier ligt waarde voor maximale doorvoer . <\ / P > De blauwe lijn vertegenwoordigt toenemende stapbelasting tijdens test . <\ / P >< H2 id = "toc-hId--426753319">De Ideale Prestatiecurve<\ / H2 >< img src = "https://us.v-cdn.net/6038851/uploads/images/17240i39DD4BF543301408/theoretical_performance_curve.png" role = "button" title = "theoretical_performance_curve.png" alt = "theoretical_performance_curve.png" \/ ><\ / span ><\ / P > Idealiter zal responstijdcurve dezelfde vorm hebben als bovenstaande groene lijn . Deze wordt genomen op hetzelfde punt in test als maximale doorvoer . <\ / P > De blauwe lijn vertegenwoordigt toenemende stapbelasting tijdens test . <\ / P >< H1 id = "toc-hId-1931676795">JMeter Rapport<\ / H1 > Bijgevoegd bij naturalearth1.zip-project is Apache JMeter-rapport genaamd naturalearth1_run1 binnen map reports . <\ / P >< UL >< LI > Openen index.html toont meerdere grafieken en tabellen ter ondersteuning analyse <\ / LI ><\ / UL >< H1 id = "toc-hId-124222332">< img src = "https://us.v-cdn.net/6038851/uploads/images/17247iF369998FE40007C4/report_folder.png" role = "button" title = "report_folder.png" alt = "report_folder.png" \/ ><\ / span ><\ / H1 >< H2 id = "toc-hId--855987471"> <\ / SPAN>Werkelijke Doorvoercurve<\ / H2 >< UL >< LI >Uit rapport:<\ / SPAN >< UL class= "lia-list-style-type-circle">< LI >Onder Grafieken --> Doorvoer , staat Hits Per Second-grafiek waar aanvraagdoorvoer uit test geplot wordt<\ / SPAN > < UL class= "lia-list-style-type-square">< LI >Aangezien test zo is opgebouwd dat elke transactie slechts één aanvraag bevat , "hits per seconde" is gelijk aan zowel transactions/sec als requests/secHet systeem behaalde een maximale doorvoer van ongeveer 80 transactions/sec (of 80 requests/sec) Werkelijke Prestatiecurve

Uit het rapport:
- Onder Charts-->Response Times, is de Time Vs Threads grafiek te vinden waar de request-prestatie van de test wordt uitgezet
  - Alle items behalve "/pvtserver/rest/services/NaturalEarth/MapServer/export" zijn eruit gefilterd (door erop te klikken in de legenda)
  - Aangezien de test is opgebouwd met elke transaction die slechts één request bevat, vertegenwoordigt de "export request" ook de gemiddelde transaction-prestatie
  - Op het punt van maximale doorvoer levert het systeem een transaction-prestatie van ongeveer 314ms of 0,3 seconden

Opmerking: Voor load tests met transactions die meer dan één request bevatten, moet een andere analysemethode worden gehanteerd

Resultaten Vergelijken

Nadat u de test van uw systeem hebt voltooid met de meegeleverde gegevens en Test Plan, kunt u de resultaten vergelijken met die vermeld in dit artikel. Dit kan een benaderende maatstaf bieden om twee systemen met elkaar te vergelijken.

Om het Apache JMeter Test Plan te downloaden dat in dit artikel is gebruikt, zie: naturalearth1.zip
Om de Natural Earth subset van gegevens te downloaden die in dit artikel is gebruikt, zie: Natural_Earth_Test_Data

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.

Vind meer berichten getagd met

Configuration & Integration

Strategy & Planning

Architecture & Security

Reacties

AaronLopez

Actual Performance Curve chart adjusted to show the response time point that corresponds more accurately to the maximum throughput.

ChiefKeefSosa300

hello sir @AaronLopez

i had a problem running this test.

i published the natural earth map as service, name it as NaturalEarth_MIL1.

change the parameter accordingly in jmeter

the result tree showed me this

any help regarding this?

AaronLopez

Hi @ChiefKeefSosa300 (tq),

Would you be able to delete one of the "image/png Validation" elements and try playing the test again?

These validations items are looking to see if the content returned from ArcGIS Server looks like a png image (this is the default image format this test requests). If it does not match a png signature, it fails the request. Failing a request whose response is not expected is a common strategy when you want to know if your test encounters an error.

Aaron

ChiefKeefSosa300

hi sir @AaronLopez,

per your suggestion i disabled the image/png validation and results go green again.

i just wanna ask about this statement:

"A load test that is sending in the requests to the map service consistently is an important for establishing a reliable benchmark. Can the test request a BMP image format instead of a PNG or ask for data to be in a different spatial reference other than the default of 4326? Yes, but changing such options may impact the performance and scalability of the test so it is recommended to leave this Test Plan settings as is."

does this mean my test failed wholly? or my arcgis server doesnt meet the benchmark requirement?

please enlighten me good sir.

thanks again.

AaronLopez

Hi @ChiefKeefSosa300 (tq),

These are really thoughtful questions, thank for asking them!

The statements about changing the output format to BMP or utilizing another the spatial reference are mentioned with respect to the that specific test. But they need more context...

I favor PNGs over BMPs as the former (Portable Network Graphics) is generally much faster to generate than the latter (Bitmap Image). For example, an export map request that creates a PNG is about 87KB. Using a BMP for the same area, the resulting image is around 15MB. The drastic difference in size would impact scalability (as more network bandwidth is required per request). That said, if your application or workflow requires BMP, then that is the way to go and your benchmark should reflect that. There is nothing wrong with using BMP as an image format for a vector data benchmark, but you should get more throughput by using PNG.

As for the spatial reference, this test used bounding boxes in a geographic coordinate system of "WGS 1984" (WKID 4326) because that is what the data (and published service) was originally in. Of course, there are many different spatial references. The goal when possible, is to try to avoid projecting-on-the-fly. In other words, if the data (and service) are in "WGS 1984" and you ask for "NAD27" (using the appropriate NAD27 bounding box), ArcGIS Server should appropriately fulfil the request. However, while very convenient, this transformation between coordinate systems comes at a performance cost. If you use this test and data as a benchmark, "WGS 1984" (WKID 4326) are an optimal choice. But, if you are wanting to build a benchmark test against your data that is in another coordinate system, I would use bounding boxes in that coordinate system to ensure you can get the best performance.

So to conclude, does using BMP or another coordinate system fail the test, not at all. Performance would be impacted, but you still have a good "measuring stick". As long as the test parameters are known and kept constant between runs over time, you'll have a reliable benchmark regardless of the options used.

Hope this helps.
Aaron

ChiefKeefSosa300

Hi @AaronLopez , thanks for lengthy explanation regarding the test. However,

Im using your test plan to test my arcgis portal but using different map service, the result of the graph is like this (100 users for 5 minutes), is this acceptable result? seems weird and different from yours.

Hits per sec

time vs threads

AaronLopez

Hi @ChiefKeefSosa300,
It depends. You stated you tested a different map service. Does that mean different data than natural
earth?
If yes, each dataset will have its own profile for performance and scalability because the geometry density and complexity can vary. Your data may have more (or less) layers and each layer may have more (or less) attributes.
If no, and you also tested natural earth, then there is a greater chance of seeing a similar profile for performance/scalability, but there are still other variables which can impact response time and throughput like the system architecture (number of machines) and hardware (number of CPUs, CPU speed and memory).

Hope this helps.
Aaron

ChiefKeefSosa300

Hi sir @AaronLopez,

I think i made wrong kind of test because i use the same datasets (project folder) for natural earth but the service name and webserver name is different.

I checked the csv file for each datasets and the home column said "eistsrv05.esri.com_443__Natural_Earth_quick_start_for_ArcMap" so yeah i guess the test result is invalid. But can it be done like this? Use the same datasets for natural earth but different map service? if not how can one acquire its own datasets. Thank you

ChiefKeefSosa300

Hi @AaronLopez ,

i overlooked ur writing about benchmark datasets "Any dataset can be used for a benchmark as long as it is kept constant where changes like feature class additions, updates, deletes and versions are not being made. This consistency helps create a dependable "standard" since it is a non-moving target. The test data can be private (e.g. proprietary) or public domain based."

So I guess my results are real and ok.

Thanks btw

EduardBeneke

Hi @AaronLopez

These tutorials are great. I am looking at utilising them to produce an end-to-end full test suite (including GP, admin tasks, building caches etc).

One of the pain-points we are currently experiencing is with the publishing of a large service, rather than the consumption of the service. Is there a way to publish this dataset using JMeter, then do some performance tests on it, and then delete it? We only see the performance issues through Pro, so need to be able to reproduce that exact process.

AaronLopez

Hi @EduardBeneke,

Yes, you could probably construct a JMeter test to perform the publishing of a large service.
This effort would most likely involve an SD file (a service definition that was previously created from ArcGIS Pro) and some asynchronous JMeter test logic.

However, the publishing of a service is generally considered an administrative function.
While the functionality of publishing a service to work as intended is very important, whether it is slow or fast is not as high a priority (just as long as it still works).

That said, here are some reasons that come to mind that might cause service publishing to have slow performance:

When publishing the service, "copy all data" is selected under the Data and Layer Type section
- While there are very good reasons to do this, one of the considerations is that ArcGIS Pro will need to upload all the data listed in the Contents pane in the project to ArcGIS Enterprise...for large datasets this can take quite awhile
The network between ArcGIS Pro and ArcGIS Enterprise has measurably latency
- If you are publishing from your local machine into the cloud or into a deployment that is physically far away, then performance (of many different operations) could be impacted
  - In this case, try publishing from an ArcGIS Pro that is on the local network of ArcGIS Enterprise
  - Alternatively, if the data resides in an Enterprise Geodatabase, consider publishing with the Reference registered data (Map Image and/or Feature) option
  - As another alternative, consider using the "Save As Offline Service Definition" when attempting to share/publish the service
    - This will create an SD file (which might be large and take some time to create), but you take that hit once. Then when you want to republish, you can do it right from manager over the web.
The PublishingTools.GPServer service is busy publishing other services
- By default, up to 3 instance can run at a time
- I list this as a possibility, but it would probably be unlikely

Hope that helps

Aaron

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.