Benchmark ArcGIS Enterprise...De Oorspronkelijke Aanpak
Een tijdje geleden besprak ik het gebruik van de Natural Earth dataset met een vooraf geconfigureerde Apache JMeter test om een benchmark van een ArcGIS Enterprise implementatie uit te voeren. De resultaten van die test konden vervolgens worden vergeleken met runs van andere implementaties om een vergelijkend beeld te krijgen van de prestaties en schaalbaarheidskenmerken van de onderliggende hardware. Deze aanpak had enkele voordelen:
- Natural Earth is gratis GIS data
- Beschikbaar voor openbaar gebruik
- Laag tot matige datacomplexiteit (makkelijk mee te werken)
- Testplan bevatte een stapsgewijze belasting om schaalbaarheidsmogelijkheden te observeren
Hoewel nuttig en een goede meetlat, betekende het schaalbaarheidscomponent dat de test meestal lang zou duren (wat ook wat complicaties toevoegde). Ik vroeg me af of er een eenvoudigere manier was om alleen de verwerkingshardware (bijv. de CPU) te benchmarken, maar nog steeds via ArcGIS Enterprise:
- Was het mogelijk om JMeter vanuit een alleen-prestatie perspectief te gebruiken?
- Kon ik een test maken om ArcGIS Enterprise te benchmarken zonder een onderliggende FGDB of enterprise geodatabase dataset (wat de algehele inspanning zou vereenvoudigen)?
Het blijkt dat het antwoord ja is!
Benchmark ArcGIS Enterprise...Een Alternatieve Aanpak
Oké...ik spreek in halve waarheden. De nieuwe benchmarktest is niet afhankelijk van een FGDB of eGDB dataset-gebaseerde service, maar heeft wel wat data nodig. Om het simpel te houden, wordt de data (bijv. vooraf gegenereerde geometrieën) gewoon doorgegeven via de JMeter sample-elementen aan een ArcGIS resource die geen verwijzende dataset achter de schermen heeft.
Dus, hoe wordt dit gedaan?
Via de beproefde Geometry service. De geometry service van ArcGIS Server is een ingebouwde resource die toegang biedt tot veel functies voor het uitvoeren van geometrische bewerkingen. De berekeningen van deze bewerkingen (zoals buffer of generalize) kunnen eenvoudig of complex zijn (afhankelijk van wat je vraagt). Vanuit het perspectief van een prestatieanalist biedt het een fantastische manier om de CPU hardware van de machine waarop ArcGIS Server draait te benchmarken.<\/SPAN>
Opmerking: Hoewel de term ArcGIS Enterprise ArcGIS Server omvat, oefent deze benchmark primair laatstgenoemde uit (bijv. ArcGIS Server). Enige verkeer kan via de ArcGIS Web Adaptor gaan en er zal een kleine hoeveelheid Portal for ArcGIS authenticatie plaatsvinden, maar door ontwerp zal het grootste deel van het werk worden uitgevoerd door ArcGIS Server.<\/STRONG>
Voordelen van het Gebruik van de Geometry service
De Geometry service bestaat al sinds versie 9.3 in ArcGIS Server, dus hij is alomtegenwoordig. Dat maakt een test die deze gebruikt makkelijk en betrouwbaar. Omdat de data die de test aandrijft in de sleutel-/waardeparen van de verzoeken wordt geplaatst, voegt dat draagbaarheid toe (bijv. geen dataset om mee te slepen).
Opmerking: Hoewel de Geometry service al geruime tijd bij ArcGIS Server zit, staat deze standaard uit en draait niet. De service moet gestart worden en gedeeld met de juiste Portal for ArcGIS leden voordat je de test uitvoert.<\/STRONG>
Het Geometry_Functions_Benchmark Testplan
- Het downloaden en openen van het Testplan in Apache JMeter zou er ongeveer zo uit moeten zien:
- PAS DE User Defined Variables aan om bij jouw omgeving te passen

Welke Soorten Functies Moeten Worden Getest?
Voor een benchmark is het korte antwoord slechts enkele. Dit specifieke Testplan roept slechts enkele verschillende bewerkingen aan... evenals dezelfde bewerkingen op verschillende manieren (bijv. wijziging van aanvraagparameters om bewust een variant antwoord te krijgen). Dit zorgt voor mutabiliteit zodat de test niet steeds hetzelfde doet.
Hieronder is een overzicht van de bewerkingen gebruikt in deze benchmark:

Verwachte Test- en Operatieprestaties
Deze test bevat enkele bewerkingen die snel kunnen presteren en andere die meer tijd kosten. Deze snelheid varieert afhankelijk van de hardware. Uiteindelijk willen we gewoon dat ArcGIS Enterprise (bijv. Server) enkele minuten werkt zodat we een idee krijgen van de verwerkingsprestaties. Als elke operatie 10 minuten duurde (met de test vele malen langer), kan de benchmark zelf te tijdrovend en minder praktisch worden.
Voorbeeld Implementatie Architectuur
Deze benchmarktest werd uitgevoerd in een lab tegen twee verschillende servers (bijv. eenmaal per server):
- ArcGIS Enterprise -- Machine #1 (oudere hardware)
- Intel Xeon E5-4650, 2.70 GHz
- SPECint_base2006
- Scoor: 50.5
- 32 verwerkingskernen
- HyperThreading uitgeschakeld
- 64GB RAM
- 10Gbps netwerk
- ArcGIS Enterprise -- Machine #2 (nieuwere hardware)
- Intel Xeon Gold 6126, 2.60 GHz
- SPECint_base2006
- Scoor: 71.9
- 24 verwerkingskernen
- HyperThreading uitgeschakeld
- 128GB RAM
- 10Gbps netwerk
Opmerking: Aangezien deze testinspanning meer gericht was op snelheid dan doorvoer, werden SPECint_base cijfers gebruikt in plaats van SPECint_rate_base.<\/STRONG>
Uitvoering Benchmark Test
Voor langdurige tests wordt aanbevolen het Testplan niet binnen de GUI uit te voeren. Aangezien dit echter een relatief korte test is, is de impact minimaal.
Opmerking: Bij het uitvoeren van elke test wordt altijd aanbevolen om starttijd en verwachte duur 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 betreffende ArcGIS Enterprise Site (bijv. productieomgeving). Daarnaast helpt dit systeemruis door andere activiteiten en gebruik te voorkomen die de testresultaten kunnen "vervuilen".<\/STRONG>
Resultaten
Nadat de User Defined Variables waren aangepast naar de juiste omgeving (Machine #1…devlab05), werd de benchmark direct in JMeter GUI uitgevoerd. De resultaten zijn te zien in het View Results in Table element:
- Voor gemak berekent het Testplan automatisch de totale testduur, direct in de naam van de laatste operatie
- Dit maakt benchmarktijd makkelijk afleesbaar vanuit de tabel
<\/span><\/SPAN><\/P>Zoals verwacht had de eerste machine meer tijd nodig om dezelfde bewerkingen te voltooien. Dit resulteerde in een meetbaar verschil in prestaties tussen de twee machines.<\/SPAN><\/P>Machine #13devlab05Duur van de benchmark: 259946 ms<\/LI><\/UL><\/LI>Machine #23eistsrv05Duur van de benchmark: 181441 ms<\/LI><\/UL><\/LI><\/UL>Percentage verandering berekenen<\/H2>Aangezien de reactietijden lager waren (bijv. sneller) met nieuwere hardware (vergeleken met de eerste run op oudere hardware), zullen we een procentuele afname<\/EM> berekenen:<\/P>Eerst, originele servertijd - nieuwere servertijd = de afname<\/LI>Vervolgens, de afname originele servernummer 100 = het % afname<\/LI><\/UL>(259946 ms - 181441 ms) \/ 259946 ms = 0.302<\/P>0.302 x 100 = 30.2% <\/P>De benchmarktijden van de oudere hardware (ons startpunt) waren 30% lager dan die van de nieuwere hardware<\/U>. Deze procentuele verandering suggereert een meetbare verbetering bij gebruik van de nieuwere hardware.<\/P>Schatting van procentuele verandering op basis van SPEC<\/H2>Laten we de SPEC-ratio gebruiken met de benchmarktijd van de oorspronkelijke run om de target_time (benchmarktijd op de nieuwere machine) te voorspellen. Dit kan helpen om te begrijpen of ongeveer dezelfde procentuele verandering geschat kan worden.<\/P>(Baseline_SPEC x Baseline_Time) = (Target_SPEC x Target_Time)<\/P>((Baseline_SPEC x Baseline_Time) \/ Target_SPEC) = Target_Time<\/P>(36.875 x 259946 ms) \/ 53.75 = 178335 ms (afgerond naar beneden op de dichtstbijzijnde seconde)<\/P>(259946 ms - 178335 ms) \/ 259946 ms = 0.314<\/P>0.314 x 100 = 31.4%<\/P>Uit deze voorspelling werd geschat dat de oudere hardware 31% lager presteerde dan met de nieuwere hardware. Dit komt zeer dicht in de buurt van de procentuele verandering die werd berekend op basis van de waargenomen benchmarktijden.<\/U> <\/P>Toekomstige hardware<\/H1>
<\/span>Processorarchitecturen en CPU-snelheden verbeteren altijd. Uiteindelijk<\/EM> kan zo'n benchmarktest (zoals die nu is opgebouwd) slechts een minuut of enkele tientallen seconden duren om uit te voeren (wat een geweldig probleem om te hebben). Op dat moment kan complexiteit aan de test worden toegevoegd om de duur ervan te verlengen zodat deze beter aansluit bij de nieuwe technologie.<\/P>Je hebt misschien gemerkt dat de laatste transactie in de test was uitgeschakeld. Dit verzoek voor een buffer van 1000 punten met een afstand van 10000 meter en een eenheid van 9035 (Internationale Meterafstand) kost wat tijd om te berekenen (zelfs op degelijke hardware). Het was uitgeschakeld om de uitvoeringstijd tot een redelijke duur te verkorten. Indien nuttig, kan het worden ingeschakeld als een extra berekening, afhankelijk van de CPU-snelheid van de betreffende implementatie.<\/P>Slotgedachten <\/H1>Zoals vermeld in andere community-artikelen, is er geen enkele service of functie die het volledige bereik en diepte van ArcGIS kan omvatten. De Geometry-service is echter een bron die een deel vertegenwoordigt van het geweldige vakgebied GIS dat gemakkelijk te gebruiken is. Dit maakt het een goede optie voor benchmarktestinspanningen.<\/P>Een snelle reactietijd draait toch vooral om CPU-snelheid?<\/H2>Voor deze Geometry-benchmarktest wel. Voor echte services is verwerkingssnelheid echter niet de enige factor.<\/P>Serverhardwarecomponenten zoals schijfsnelheid, beschikbare geheugen, netwerksnelheid zijn andere middelen die reactietijden kunnen verbeteren (naast CPU-snelheid). Samen hebben ze allemaal een positieve invloed op de gebruikerservaring.<\/P>Deze benchmark richtte zich op CPU-prestaties omdat dit een groot deel is van het clientverzoek-serverantwoordproces, maar zoals zojuist vermeld, is het niet het enige servermiddel bij het rekening houden met andere mogelijke ArcGIS-services.<\/P>Hoe zit het met andere CPU-vergelijkingstools?<\/H2>
<\/span>Er zijn veel hulpprogramma's die verschillende onderdelen van serverhardware kunnen profileren en testen met een hele reeks oefeningen. Deze tests zijn geweldig en voegen zeker waarde toe voor het begrijpen van de hardware. Nogmaals, er is geen enkele test die alles binnen GIS kan vertegenwoordigen. Maar hopelijk kan dit Geometry Benchmark Test Plan een nuttig hulpmiddel zijn in het arsenaal van analisten. <\/P>
<\/P>Om het Apache JMeter Test Plan te downloaden dat in dit artikel is gebruikt, zie: geometry_functions_benchmark1.zip<\/<A>\u00a0<\/<STRONG>\u00a0<\/<\p>\u00a0<\/<\p>\u00a0<\/<\p>\u00a0<\/<\p>\u003cSTRONG\u003EAttributie\u003c/STRONG\u003E<\/<p>Bron: Bestand:Wikimedia_Foundation_Servers-8055_43.jpg
Beschrijving: Rack-gemonteerde servers PowerEdge van generatie 11
Auteur: Victorgrigas - Eigen werk
Gemaakt: 16 juli 2012
Geüpload: 20 juli 2012
Licentie: CC BY-SA 3.0, Link
Bron: Bestand:Cpu-processor.jpg
Beschrijving:
Auteur: Fx Mehdi - Eigen werk
Geüpload: 30 mei 2019
Licentie: Creative Commons Attribution-Share Alike 4.0 International