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; } } }

Hardwaregebruik vastleggen tijdens een Apache JMeter loadtest (gevorderd)

AaronLopez

Hardwaregebruik vastleggen tijdens een Apache JMeter Load Test

Gemeten transactiedoorvoer en responstijden zijn cruciale gegevens van elke ArcGIS Enterprise load test, maar het vastgelegde hardwaregebruik van de implementatiemachines levert ook vitale informatie. Samen stellen deze testartefacten in staat tot een juiste analyse van de mogelijkheden en efficiënties van de Site.

Het bepalen dat een applicatie of feature service een bepaald niveau van doorvoer heeft bereikt is goed, maar het bevestigen van de schaalbaarheidskenmerken terwijl ook het vastgelegde processorgebruik van de geteste workload wordt onderzocht is nog beter.

Dit artikel bespreekt verschillende manieren om het hardwaregebruik van de machine vast te leggen. Dit resourcegebruik is een geweldige aanvulling op de resultaten van een Apache JMeter load test van ArcGIS Enterprise en kan helpen bij verdere analyse. Het artikel richt zich op de meest voorkomende scenario's met gratis tools en hulpprogramma's voor Windows en Linux.

Vastlegstrategieën

Helaas is er geen one size fits all voor het vastleggen van hardwaregebruik in een load test. Gezien de mogelijkheid van een veelheid aan verschillende omgevingen (Windows, Linux, Cloud, Kubernetes, Docker, enzovoort) of gebrek aan vereiste toegang en permissies, kunnen er gevallen zijn waarin u uw strategie en methodologie moet aanpassen om de gebruiksinformatie van uw hardware vast te leggen en te monitoren terwijl de Apache JMeter tests draaien.

Bijvoorbeeld, perfmon (bijv. Performance Monitor) is gratis en inbegrepen bij elke instantie van Microsoft Windows en kan uitstekend werken wanneer alle machines in de omgeving op Windows draaien. Het is de frontend voor verschillende Windows-technologieën (bijv. WMI, DCOM) en samen bieden ze een veelzijdig kader voor het monitoren van hardwaregebruik in "real-time" met grafieken of het scripten van een resourcevastlegging naar een datafile.

Echter, perfmon is niet beschikbaar voor Linux dus is een ander hulpmiddel (bijv. dstat) nodig om equivalente informatie vast te leggen. Natuurlijk kunnen zelfs bij een volledig Windows-opstelling uitdagingen ontstaan met de perfmon-benadering, zoals bij restrictieve cloudomgevingen. Maar zijn er andere manieren om deze waardevolle machinedata op te nemen? We zullen het antwoord op die vraag later in dit artikel verkennen.

Welke informatie moet de load test vastleggen?

Wanneer GIS-werk zoals het genereren van een kaartafbeelding of het berekenen van een Geoprocessing serviceverzoek wordt verzonden naar een ArcGIS Enterprise-implementatie, gebruiken de servermachines die aan het antwoord werken verschillende hardwarebronnen om de taak te voltooien. Idealiter gebeurt het meeste werk in de centrale processorunit (CPU), maar dat is niet altijd het geval.

Ongeacht de technologie die wordt gebruikt om gebruik te monitoren en vast te leggen voor uw load test, zijn er vier primaire hardware-teller categorieën die alle servermachines hebben:

Processor
Geheugen
Netwerk
Schijf

Elke categorie heeft verschillende meetwaarden die kunnen worden gebruikt om het gebruik van die resource weer te geven. Het is niet noodzakelijk (of aanbevolen) om elke beschikbare processormaatstaf tijdens een test vast te leggen... alleen de essentiële. Met andere woorden, degene die nodig zijn om typische load test vragen te beantwoorden of het specifieke verhaal dat u wilt vertellen.

Typisch omvatten enkele belangrijke meetwaarden het volgende:

Processor
- Gebruik percentage
Geheugen
- Beschikbaar (MB of bytes)
- Gebruikt (MB of bytes)
- Gebruikt percentage
Netwerk
- Verzonden (MB of bytes)
- Ontvangen (MB of bytes)
Schijf
- Idle percentage
- Wachtrij lengte
- Lezen (MB of bytes)
- Schrijven (MB of bytes)

Opmerking: Als uw servers meerdere schijven hebben, wordt sterk aanbevolen om op al deze afzonderlijk te verzamelen. Met andere woorden, behandel de C-schijf, D-schijf en E-schijf als verschillende resources bij het vastleggen. Technisch gezien is het mogelijk meerdere actieve netwerkapparaten te hebben maar dit komt niet vaak voor.

De Performance Monitor-interface verzamelt gegevens van verschillende handmatig toegevoegde hardware-metrics (aan perfmon):

Opmerking: Sommige methodologieën voor het vastleggen van gebruik slaan waarden op in bytes, terwijl andere megabytes gebruiken. Beide zijn prima, maar het is belangrijk te begrijpen welke wordt vastgelegd voor analyse en rapportagepresentatie van de data.

Opmerking: Samen met de transactiedoorvoer (bijv. transacties/sec) en transactie-responstijden (bijv. seconden), vormen bovenstaande metrics het grootste deel van de Kernprestatie-indicatoren (KPIs) van een load test. KPI's helpen bij het evalueren en benchmarken van het succes van een bepaalde test of inspanning ten opzichte van gedefinieerde testdoelen (bijv. het Testplan).

Meetinterval

Typisch draait een load test (met primaire focus op schaalbaarheid) niet langer dan een uur of twee. Omdat dat als relatief kort wordt beschouwd, is het logisch om het hardwaregebruik met een snel interval (bijv. korte frequentie) van 5 tot 10 seconden vast te leggen. Dit helpt ervoor te zorgen dat voldoende data wordt verkregen voor grondige analyse. Als het meetinterval 1 minuut of langer is, kunnen significante invloeden op de hardwarebronnen (door de test) gemist worden.

Opmerking: Monitoringsoftware kan al actief zijn op uw netwerk die periodiek hardwaregebruik verzamelt van uw ArcGIS Enterprise-servers. Als gegenereerde rapporten beschikbaar zijn, kunnen deze worden gebruikt voor load test analyse zolang het meetinterval kort is (bijv. 5 tot 10 seconden). Voor load test analyse bent u geïnteresseerd in gedetailleerde metrics over enkele uren in plaats van brede metricdekking over een hele dag.

Het verschil tussen vastleggen en monitoren

De termen "vastleggen" en "monitoren" van hardwaregebruik worden vaak door elkaar gebruikt. Echter, voor Apache JMeter-testdoeleinden richt dit artikel zich op het vastleggen van gebruik boven monitoring ervan. Het belangrijkste verschil hier is dat vastleggen betekent dat we informatie opnemen of opslaan voor eenvoudigere post-test analyse.

Testclients (Load Generator Machines)

Bij het vastleggen van hardwaregebruik vanuit een load test tegen ArcGIS Enterprise is het beste testpraktijk om ook gebruik te meten vanaf de Test Client machine(s).
Begrijpelijkerwijs ligt de meeste focus op observatie van serverresources, maar ook de hardware van testclients kan een bottleneck zijn. Als deze machines niet genoeg capaciteit hebben (bijv. processor, geheugen, netwerk of schijf), zal dit negatieve invloed hebben op hun vermogen om load tegen uw implementatie te genereren!

Begrijp uw server-baselines

Als u niet erg bekend bent met de hardware van uw ArcGIS Enterprise-implementatie, wordt aanbevolen om resourcegebruik te observeren terwijl het systeem idle is. Dit "gebruik" helpt bij het vormen van een mentaal beeld van het beste scenario. Met andere woorden, hoe ziet de machine eruit wanneer software en services draaien maar niemand deze gebruikt? In zo'n scenario zou resourceactiviteit uit alle vier hardwarecategorieën minimaal moeten zijn.
Een load test hoeft deze informatie over de "idle state" niet op te nemen maar het is goed bewust te zijn hoe dit eruitziet.

Opmerking: Hulpmiddelen zoals Taakbeheer (voor Windows) of top (voor Linux) zijn geweldige tools om handmatig snel systeemresourcegebruik te bekijken. Echter zijn ze niet ideaal om gebruik uit alle categorieën naar een bestand op te slaan.

Taakbeheer-weergave van systeemresourcegebruik (Windows):

top-weergave van systeemresourcegebruik (Linux):

Veelvoorkomende voorbeelden voor gebruiksvastlegging

Gebruik Perfmon (om gebruik buiten load test vast te leggen)

Aangenomen dat de vereiste permissies beschikbaar zijn voor uw gebruikersaccount in Windows, is perfmon één van de gemakkelijkste manieren om hardwaregebruik vast te leggen voor load testing analyse. Performance Monitor (en de ondersteunende technologieën) kan het gebruik vastleggen van de lokale machine of meerdere externe servers, gelijktijdig.<\/P>

Opmerking: Ter herinnering, de beschikbare metrics voor perfmon binnen elke hardwaregroep zijn talrijk.<\/STRONG><\/FONT>
Er is ook een grote hoeveelheid softwaremetrics die kunnen worden vastgelegd. Maar in dit geval is minder meer. Slechts een klein aantal tellers is nodig voor de meeste situaties.<\/STRONG><\/FONT><\/P>Zoals eerder vermeld, waar je tegen overwegingen kunt aanlopen:<\/P>De ArcGIS Enterprise-implementatie draait op Linuxperfmon is niet beschikbaar voor LinuxDe gemakkelijkste oplossing is om een andere methode te gebruiken om de informatie te verzamelen (later besproken)<\/LI><\/UL><\/LI><\/UL><\/LI>De implementatie bevindt zich in de cloudHet draaien van erfmon in de cloud om te verzamelen van andere implementatiemachines (in de cloud) is technisch mogelijk maar gebruikt achter de schermen netwerkprotocollen die doorgaans in de omgeving worden geblokkeerdDe gemakkelijkste oplossing hier is om perfmon handmatig op elke cloudmachine uit te voeren en de gegenereerde output te verzamelen wanneer de test is voltooid<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Het starten van perfmon in Windows is zo eenvoudig als het uitvoeren van:<\/P>Uitvoeren --> perfmon<\/LI><\/UL>Vanaf daar kun je elke machine toevoegen evenals elke respectieve hardwaremetric en teller. Hoewel dit zeer krachtig is, kan het tijdrovend zijn en mogelijk gevoelig voor typefouten!<\/P>In plaats daarvan is de aanbevolen strategie voor deze methode het gebruik van een PowerShell-script waarin al deze items vooraf zijn gedefinieerd.<\/P>Het volgende verzamelt belangrijke perfmon-metrics (die al zijn gedefinieerd) uit de vier primaire hardwarecategorieën en doet dit voor vier verschillende machines (die je kunt specificeren):<\/LI><\/UL> <\/P># =============================================================================== # Bijgewerkt: 2022-08-02 # Bestandsnaam: ps_get_all_continuous.ps1 # Versie: 0.1.0 # Beschrijving: Continu continu verschillende metrics verzamelen en (binaire) waarden opslaan in een bestand # Opmerkingen: Het wordt aanbevolen om met het verzamelen van metrics 20 seconden vóór het starten van de test te beginnen # omdat het initialiseren van tellers enige tijd kan duren # =============================================================================== Write-Output -InputObject 'Alle metrics verzamelen (continu)...' # Variabelen # Windows Perfmon Teller(s) $counters = "Processor(_Total)\% Processor Time","Memory\Available MBytes","Memory\Committed Bytes","Memory\% Committed Bytes In Use","Network Interface(*)\Bytes Received/sec","Network Interface(*)\Bytes Sent/sec","LogicalDisk(_Total)\% Idle Time","LogicalDisk(_Total)\Disk Read Bytes/sec","LogicalDisk(_Total)\Disk Write Bytes/sec" # Machines om van te verzamelen $computers = @('server1.domain.com','server2.domain.com','server3.domain.com','server4.domain.com') # Tijd in seconden tussen elke monsterverzameling $sampleinterval = 10 $date = (Get-Date) $dyndate = '{0:yyyyMMddTHHmmss}' -f $date # 20220303T140044 # Bestandsnaam $filename = "perfmon_all_continuous" # Uitvoerbestandstype (keuzes zijn blg, csv, of tsv) $outputfiletype = "blg" # Uitvoerbestand $outputfile = '{0}_{1}.{2}' -f $filename, $dyndate, $outputfiletype # Get-counter Write-Output -InputObject ('Startdatum en tijd: {0}' -f $date) Get-counter -Computername $computers -Counter $counters -Continuous -Sampleinterval $sampleinterval | Export-counter -Force -FileFormat $outputfiletype -Path $outputfile <\/code><\/pre> <\/P><UL><LI>De metrics worden elke 10 seconden verzameld totdat je Ctrl-C indrukt in het PowerShell-venster<\/U>. De informatie wordt opgeslagen in een binair geformatteerd bestand dat je kunt openen in Windows (voor verdere analyse of transformatie):<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49356iC6B4C3B9199D2CF8\/capturehardware_powershell_start_output.png" role="button" title="capturehardware_powershell_start_output.png" alt="capturehardware_powershell_start_output.png" \/><\/P>Opmerking: Het wordt aanbevolen om dit Powershell-script ongeveer 20 of 30 seconden voor het starten van je load test te starten omdat het initialiseren van tellers niet onmiddellijk is en een momentje duurt.<\/FONT><\/STRONG><\/P><UL><LI>Je kunt het *.blg-bestand op elk moment tijdens het vastleggen openen, maar de nieuwste informatie wordt pas weggeschreven en opgeslagen in het bestand nadat je Ctrl-C hebt ingedrukt in het PowerShell-venster waar het script draait.<\/LI><LI>Dubbelklikken en openen van het *.blg-bestand zou er ongeveer als volgt uit moeten zien:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49377i9D7D47D522AD17A4\/capturehardware_powershell_results.png" role="button" title="capturehardware_powershell_results.png" alt="capturehardware_powershell_results.png" \/><\/P>Het eindresultaat is een output die er erg vergelijkbaar uitziet met wat we hebben vastgelegd. Echter, in dit geval is het proces geautomatiseerd (wat een goede zaak is).<\/SPAN><\/P>Vanuit deze interface in Performance Monitor kun je metrics selecteren/deselecteren voor specifieke isolatie, de grafiek exporteren als afbeelding, de ruwe data opslaan naar een ander formaat zoals CSV, of gebruiksanalyse uitvoeren van alle verzamelde machines. Erg krachtig!<\/SPAN><\/P>Opmerking: Performance Monitor-scripts integreren niet direct in JMeter. <\/STRONG><\/FONT><\/SPAN><\/P>Opmerking: Voor cloudimplementaties moet je mogelijk het perfmon-script handmatig op elke respectieve server uitvoeren.<\/STRONG><\/FONT><\/SPAN><\/P><H3 id="toc-hId--464400263">Gebruik van dstat (Om gebruik buiten load test vast te leggen)<\/H3>dstat is een gratis commandoregeltool (geschreven door dag@wieers.com) beschikbaar voor (of bij) de meeste Linux-distributies die hardwaregebruik vastlegt (en monitort). Hoewel de utility al enkele jaren niet meer is bijgewerkt, is hij vrij robuust en gemakkelijk te scripten.<\/P><UL><LI>dstat terminaloutput bij uitvoeren zonder opties:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49381i3426B23A73682927\/capturehardware_dstat_monitor.png" role="button" title="capturehardware_dstat_monitor.png" alt="capturehardware_dstat_monitor.png" \/><\/P>Het volgende draait op je Linux-server en legt hardwaregebruik vast naar een csv-bestand elke 5 seconden totdat je het handmatig stopt met Ctrl-C<\/U>:<\/P><UL><LI>[gisadmin@pesrv04 ~]$ dstat -tTcmn --disk-util -d --nocolor --noheaders --output dstat_20220823.csv 5<\/STRONG></LI></UL ><img src = "https:\/ \/us.v-cdn.net \/6038851 \/uploads \/images \/49383i12F99873FC093EA3 \/capturehardware_dstat_capture.png" role = "button" title = "capturehardware_dstat_capture.png" alt = "capturehardware_dstat_capture.png" \/ > Opmerking: Met dstat is het vastgelegde processorgebruik "idle time percentage", niet gebruikspercentage. Om het gebruikspercentage te krijgen, trek je 100 af van de waarde. De schijfgebruik is echter wel in gebruikspercentage. Bovendien bevat bovenstaande uitvoer een presentatiefomaat zodat de ruwe waarden (niet getoond) voor geheugen, netwerk en schijf worden opgeslagen als bytes. Opmerking: dstat-scripts moeten handmatig en afzonderlijk op elke Linux-machine in de implementatie worden uitgevoerd. Ze integreren niet direct in JMeter. Zodra een load test klaar is en de scripts gestopt zijn, kunnen de CSV-bestanden worden verzameld en geanalyseerd (bijv. uitgezet of gechart in een spreadsheetprogramma).< H3 id="toc-hId-2023112570">Gebruik van Apache JMeter (Om gebruik direct vanuit load test vast te leggen)< /H3 > Hoewel het iets meer stappen heeft (en ook eigen hindernissen) dan perfmon- en dstatscripts, heeft het gebruik van Apache JMeter om hardwaregebruik vast te leggen één groot voordeel:< UL >< LI >Consistentie. Dezelfde JMeter Test Plan kan worden gebruikt om dezelfde hardwaremetrics vast te leggen van Windows en Linux (en Mac)< UL >< LI >Dit wordt bereikt door verschillende gratis softwareonderdelen:< UL >< LI >De <A href="https://jmeter-plugins.org/wiki/PerfMon/" target="_blank" rel="noopener nofollow noreferrer">jp@gc - PerfMon Metrics Collector</A> extensie die aan JMeter wordt toegevoegd  < UL >< LI >Deze component wordt gebruikt om te definiëren welke metrics verzameld moeten worden en van welke machines< /LI >< / UL >< / LI >< LI >De <A href="https://github.com/undera/perfmon-agent/blob/master/README.md" target="_blank" rel="noopener nofollow noreferrer">PerfMon Server Agent</A> tool die draait in een Java Runtime Environment (JRE) op elke server in de implementatie < UL >< LI >Deze component voert de daadwerkelijke verzameling uit op elke server en stuurt de gegevens terug naar JMeter< /LI >< / UL >< / LI >< / UL >< / LI >< / UL >< / LI >< / UL > De jp@gc - PerfMon Metrics Collector component kan eenvoudig aan het Test Plan worden toegevoegd via de JMeter Plugins Manager (te vinden onder "PerfMon (Servers Performance Monitoring):<img src="https://us.v-cdn.net/6038851/uploads/images/49709i9536381D99067E93/capturehardware_jmeter_pluginmanager.png" role="button" title="capturehardware_jmeter_pluginmanager.png" alt="capturehardware_jmeter_pluginmanager.png" /> De PerfMon Server Agent-component is relatief eenvoudig toe te voegen, maar er zijn een paar extra stappen nodig om het goed te laten werken.<\/SPAN><\/P>Opmerking: Door een bug in de sigar-amd64-winnt bibliotheek crasht de ServerAgent als u de out-of-the-box bibliotheek gebruikt met de JDK of JRE hoger dan versie 8. De oplossing is om de bibliotheek te patchen of een up-to-date versie 8 JRE te gebruiken.<\/STRONG><\/FONT><\/P><A href="https:\/\/www.openlogic.com\/openjdk-downloads" target="_self" rel="nofollow noopener noreferrer">OpenLogic<\/A> biedt gratis, periodiek bijgewerkte v8 OpenJDK (en JRE) releases aan om te downloaden voor Windows, Linux en Mac. Hoewel de JDK zou werken, wordt in dit geval de JRE aanbevolen omdat het een kleiner pakket is om te downloaden maar nog steeds de omgeving biedt die nodig is voor het uitvoeren van de agent.<\/FONT><\/P>Opmerking: Zowel de 32bit als 64bit JRE werkt voor de ServerAgent.<\/STRONG><\/FONT><\/P>Opmerking: De OpenLogic JDK of JRE kan ook worden gebruikt om Apache JMeter zelf uit te voeren.<\/STRONG><\/FONT><\/P><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49406iEBD98A1C9C85F57D\/capturehardware_openlogic_download.png" role="button" title="capturehardware_openlogic_download.png" alt="capturehardware_openlogic_download.png" \/><\/span><\/FONT><\/P><UL><LI>De ServerAgent en OpenLogic JRE uitgepakt in dezelfde map:<\/SPAN><\/FONT><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49499i1001834053E61544\/capturehardware_openlogic_serveragent_explorer.png" role="button" title="capturehardware_openlogic_serveragent_explorer.png" alt="capturehardware_openlogic_serveragent_explorer.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI> De OpenLogic JRE verplaatst naar de ServerAgent-map:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49500i9E7477A4EACB100A\/capturehardware_openlogic_serveragent_jre.png" role="button" title="capturehardware_openlogic_serveragent_jre.png" alt="capturehardware_openlogic_serveragent_jre.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI>Open het bestand startAgent.bat in een editor en werk het bij met de naam van de JRE-directory die in de ServerAgent-map is gekopieerd:<\/LI><\/UL> <\/P><pre class="lia-code-sample language-csharp"><code> off\n\nset JAVAPATH=.\\openlogic-openjdk-jre-8u342-b07-windows-64\\bin\n%JAVAPATH%\\java -jar %0\\..\\CMDRunner.jar --tool PerfMonAgent %*<\/code><\/pre> <\/P><UL><LI>Sla de wijzigingen op<\/LI><LI>De C:\\JMeterAgent\\ServerAgent-2.2.3 map heeft nu een zelfstandige ServerAgent die kan worden gekopieerd naar de juiste machines om hun hardwaregebruik te verzamelen<\/LI><LI>Om de agent te starten in Windows<\/STRONG>, dubbelklik op startAgent.bat<UL><LI>De agent wordt gestart in een opdrachtvenster:<\/LI><\/UL><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49501iB7B6D67885E49A9C\/-capturehardware_serveragent_listening.png" role="button" title="capturehardware_serveragent_listening.png" alt="capturehardware_serveragent_listening.png" \/><UL><LI>De agent zal niet beginnen met "verzamelen" van metrics totdat dit wordt aangestuurd door het Apache JMeter Test Plan <UL><LI>Standaard communiceren de agent en JMeter met elkaar via TCP en UDP poort 4444<\/LI></UL></LI></UL>Opmerking: De jp@gc - PerfMon Metrics Collector gebruikt de naam "perfmon", maar maakt geen gebruik van<\/> Windows Performance Monitor-technologie.<\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <h1 id=">Het SampleWorldCities Testplan met ondersteuning voor metrische verzameling</h1> <ul> <li>Om het Apache JMeter Testplan te downloaden dat in dit artikel wordt gebruikt, zie: <a href=">sampleworldcities5.zip</a>  </li> <li>Het openen van het testplan in Apache JMeter zou er ongeveer als volgt uit moeten zien: <ul class=">li> <ul> <li>Deze test definieert vier verschillende machines waarvan hardwaregebruik wordt verzameld: <ul> <li>Een webadapter <ul> <li>De verzoeken worden ook naar dit eindpunt gestuurd</li> </ul> </li> <li>Een ArcGIS Server</li> <li>Een Portal for ArcGIS</li> <li>De testclient (de machine waarop JMeter draait) <ul> <li>De hostnaam van deze machine wordt automatisch gedetecteerd door JMeter wanneer de test wordt uitgevoerd</li> </ul> </li> </ul> </li> </ul> </li> </ul> Locatie van de JMeter Test Plan hoofdmap (bijv. de map waar het Test Plan zich bevindt) set projectdir=%~dp0 rem Naam van het JMeter Test Plan (zonder de JMX bestandsextensie) set testname=sampleworldcities5 rem Tekst toegevoegd aan het resultatenbestand van elke testrun set runname=testrun1 rem Proxy-instellingen rem set proxyhost=http:\/\/localhost rem set proxyport=8888 rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ rem *** Start je motoren *** color 20 rem Stel omgevingsvariabele in om te verwijzen in test (bijv. ${__P(env.run)}) set jvm_args="-Denv.runname=%testname%_%runname%" echo on rem *** Test gestart *** %javadir%\java.exe --illegal-access=warn %jvm_args% %heap% -jar %jmeterbin%\ApacheJMeter.jar -Jjmeter.save.saveservice.autoflush=false -n -f -t "%projectdir%\%testname%.jmx" ^ -l "%projectdir%\results\results_%testname%_%runname%.jtl" ^ -j "%projectdir%\logs\debug_%testname%_%runname%.log" ^ -e -o "%projectdir%\reports\%testname%_%runname%" ^ rem haal commentaar weg indien nodig rem -H %proxyhost% -P %proxyport% ^ rem *** Test voltooid *** echo off color 40 ping localhost -n 5 color 07

Opmerking: Het is altijd aanbevolen om de starttijd en duur van de loadtest af te stemmen met de juiste personen binnen uw organisatie. Dit zorgt voor minimale impact op gebruikers en andere collega's die mogelijk ook gebruik moeten maken van uw on-premise ArcGIS Enterprise Site. Daarnaast helpt dit om systeemruis van andere activiteiten en gebruik te voorkomen die de testresultaten kunnen "vervuilen".

Opmerking: Om verschillende redenen wordt sterk aangeraden om nooit loadtests uit te voeren op services geleverd door ArcGIS Online.

Algemene Methodologie Gids

Deze gids is niet bedoeld om alle scenario's voor het vastleggen van hardwaregebruik volledig te behandelen.

Scenario #1
- Servers
  - Windows
- Omgeving
  - On-premise
- Verzamelmachine (Test Client)
  - Windows
- Beschrijving
  - Windows-gebruik vastleggen vanaf Windows
- Moeilijkheidsgraad
  - Eenvoudig/Matig
- Aangeraden Methodologie
  - Windows Perfmon (via PowerShell-script)

Scenario #2
- Servers
  - Windows/Linux
- Omgeving
  - On-premise
- Verzamelmachine (Test Client)
  - Windows
- Beschrijving
  - Windows/Linux-gebruik vastleggen vanaf Windows
- Moeilijkheidsgraad
  - Matig
- Aangeraden Methodologie
  - JMeter Perfmon Extension en ServerAgent

Scenario #3
- Servers
  - Linux
- Omgeving
  - On-premise
- Verzamelmachine (Test Client)
  - Windows/Linux
- Beschrijving
  - Linux-gebruik vastleggen vanaf Windows/Linux
- Moeilijkheidsgraad
  - Eenvoudig/Matig
- Aangeraden Methodologie
  - dstat-commando of script

Scenario #4
- Servers
  - Windows/Linux
- Omgeving
  - Cloud
- Verzamelmachine (Test Client)
  - Windows
- Beschrijving
  - Windows/Linux-gebruik vastleggen vanaf Windows
- Moeilijkheidsgraad
  - Matig
- Aangeraden Methodologie
  - Cloud Watch/Azure Monitor (niet behandeld in dit artikel)

Scenario #5
- Servers
 - Windows
- Omgeving
 - Cloud
 Verzamelmachine (Test Client)</ ul ></ li >< li > Beschrijving < ul >< li > Windows-gebruik vastleggen vanaf Windows </ li ></ ul ></ li >< li > Moeilijkheidsgraad < ul >< li > Matig </ li ></ ul ></ li >< li > Aangeraden Methodologie < ul >< li > Voer Windows Perfmon uit (via PowerShell-script) op elke machine in de implementatie </ li ></ ul ></ li ></ ul ></ li ></ ul >< ul >< li > Scenario #6 < ul >< li > Servers < ul >< li > Linux </ li ></ ul ></ li >< li > Omgeving < ul >< li > Kubernetes </ li ></ ul ></ li >< li > Verzamelmachine (Test Client) < ul >< li > Windows </ li ></ ul ></ li >< li > Beschrijving < ul >< li > Linux container/pod-gebruik vastleggen vanaf Windows </ li ></ ul ></ li >< li > Moeilijkheidsgraad < ul >< li > Matig/Moeilijk </ li ></ ul ></ li >< li > Aangeraden Methodologie < ul >< li > Omgevingsdashboard of aangepaste resource-eindpunt (niet behandeld in dit artikel) </ li ></ ul ></ li ></ ul ></ li ></ ul >< h1 id="toc-hId-1302504300">Veelvoorkomende Uitdagingen bij het Verzamelen van Gebruikgegevens Het vastleggen van hardwaregebruik van implementatiemachines voor een loadtest is een beste testpraktijk, maar het is niet altijd mogelijk. De meest typische uitdagingen zijn: < ul >< li > Machtigingen < ul >< li > De meest voorkomende </ li >< li > Het niet hebben van toegang tot of de mogelijkheid om gebruik te verzamelen van externe servers is de meest voorkomende uitdaging </ li ></ ul ></ li >< li > Omgeving/Locatie < ul >< li > Het verzamelen van gebruik van machines op het lokale netwerk is iets anders dan het verzamelen van gebruik van machines in de cloud </ li ></ ul ></ li >< li > Besturingssysteem < ul >< li > Soms stelt het OS zijn eigen *obstakels* bij het vastleggen van het gebruik </ li ></ ul ></ li >< li > Technisch < ul >< li > Bepaalde omgevingen (bijv. Kubernetes/Docker) hebben mogelijk niet dezelfde API's voor het verzamelen van gebruik als een traditionele (fysieke of virtuele) machine </ li ></ ul ></ li ></ ul >< h1 id="toc-hId--504950163">Slotgedachten Simpel gezegd, er zijn veel manieren om hardwaregebruiksinformatie te verzamelen van de machines in een ArcGIS Enterprise-implementatie om te analyseren met uw loadtestresultaten. Wat de beste manier is om dit vast te leggen... elke manier die het beste werkt waarbij u snel de info kunt opnemen en gebruiken voor effectieve analyse. Hoewel geen enkel artikel elke situatie, omgeving en scenario kan behandelen, somt dit er verschillende methodologieën op voor het verzamelen van deze gegevens voor veelvoorkomende situaties.

Vind meer berichten getagd met

Operational Support

Strategy & Planning

Architecture & Security

Reacties

AaronLopez

Hi @ErickTGG,
Any observability tool could be used to capture operation data like CPU and memory usage from a performance/load test. And, if these reports and filters already exist and can be consumed that is definitely a good strategy.

One thing to keep in mind is that by default, many monitoring tools capture metrics for long term analysis. A common polling rate is every 1 minute or 5 minutes since they are expecting to store a lot of data (and this frequency can help with the manageability and scalability of that system).

As such, that "lower" resolution is generally not ideal for examining the impact of a load test. A typical load test runs for 1-- 2 hours. For such a short duration, higher capture intervals like 5, 10, or 20 seconds, are usually favored so a more detailed impact on the deployment's resources can be seen. This might be adjustable with most monitoring tools...not sure.
In cases where this higher resolution is not an option or maybe there is no monitoring tool even available, having the testing framework capture this type of data can be extremely valuable for the analysis.

Hope that helps.
Aaron

ErickTGG

Hey - Any reason why you haven't covered anything here with ArcGIS Monitor?

Is it that we can just create some filters in ArcGIS Monitor to view the same metrics?

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.