Aanvraag
Ook bekend als een sampler
Een HTTP request is de "kleinste" eenheid werk die je kunt definiëren om een test uit te voeren. Over het algemeen, bij het testen van ArcGIS Enterprise, kan het een URL zijn voor een resource zoals een map service, feature service of route solve, maar het kan ook een oproep zijn voor een statisch object zoals een *.css of *.js bestand.
Het protocol kan HTTP (platte tekst) of HTTPS (beveiligd) zijn en de methode kan er een van vele zijn, hoewel GET POST en HEAD typisch de meest voorkomende zijn.
Een dynamische map service aanvraag zou de volgende vorm hebben:
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
Dezelfde URL als een Apache JMeter HTTP-aanvraag:
Hoe een statische aanvraag eruit zou zien:
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter maakt ook onderscheid tussen een request en een sampler, hoewel ze beide een actie definiëren om uit te voeren. Een sampler zou de uitvoering zijn van een proces op het besturingssysteemniveau dat een bepaalde actie uitvoert, zoals het uitvoeren van een geoprocessing tool om een file geodatabase te maken of om een nieuwe SDE-versie in een enterprise geodatabase te creëren. Elke test moet ten minste één request of sampler bevatten.
Een ander type sampler is een web socket. Hoewel het lijkt op een HTTP-aanvraag doordat het een oproep doet via het "web" en beveiligd kan zijn, gebruikt het een ander protocol voor communicatie met de externe server evenals andere parameters om parameteropties te specificeren.
Transactie
Een transactie is een logische groepering van één of meer http-aanvragen. De aanvragen kunnen dynamisch en/of statisch zijn. Samen vormen deze aanvragen meestal één gebruikershandeling, bijvoorbeeld:
- Het laden van webapplicatie
- Een navigatieactie zoals pannen of zoomen
- Een zoekfunctie
- Aanmaak van een nieuwe SDE-versie binnen een Enterprise GeoDatabase
Het is geen technische vereiste om transacties in een test te gebruiken, maar dit kan de analyse aanzienlijk verbeteren omdat individuele handelingen (bijv. transacties) dan geïsoleerd kunnen worden om hun respectieve prestatiegedrag gedurende de run te tonen. Dit kan zeer informatief zijn.
Begrijpen dat alleen aanvragen voor schaal 1:72.224 prestatieproblemen hadden is erg nuttig vanuit tuning perspectief omdat je precies zou weten welke gebieden van het kaartdocument of project aangepast moeten worden
...transacties kunnen je helpen dit te bereiken.
Apache JMeter Transactie die drie aanvragen bevat van één handeling:
Test
Ook bekend als testplan of testproject
De term "test" is vrij algemeen en wordt vaak zowel als zelfstandig naamwoord (Ik heb een test gemaakt om de resource aan te roepen) als werkwoord (Ik ga de service testen) gebruikt. Transacties en aanvragen worden meestal gedefinieerd in een test. De test heeft extra opties om te configureren zoals: hoe lang de test zal duren, waar de resultaten naartoe gaan, moeten er metrics op de externe servers verzameld worden.
Verschillende frameworks gebruiken iets verschillende terminologieën voor het beschrijven van een test. In het geval van Apache JMeter wordt een test of testproject Test Plan genoemd en aangeduid met de extensie *.jmx.
Stapbelasting
Ook bekend als load
De stapbelasting is een kenmerk dat definieert hoe lang en hoeveel gelijktijdige testthreads moeten worden toegepast tijdens de test door middel van gelijkmatige, toenemende druk (bijv. vergelijkbaar met een trap). Het configureren van de test voor stapbelasting is nuttig om te begrijpen hoe een map service presteert of schaalt of hoe implementatieresources zich gedragen
naarmate er meer en meer aanvragen op worden afgevuurd. De gedefinieerde druk kan ook afnemen (tegen het einde van de test), maar hoeft niet.
Apache JMeter Thread Group (bzm - Concurrency) die een specifieke stapbelasting specificeert en visualiseert:
Constante belasting
Een constante belasting definieert ook hoe lang en hoeveel testthreads moeten worden toegepast, maar wordt meestal ingesteld voor een constante snelheid over lange periodes. In plaats van te focussen op prestaties en schaalbaarheid is deze configuratie typisch bedoeld om duurzaamheid en stabiliteit te begrijpen.
Apache JMeter Thread Group (bzm - Concurrency) die een specifieke constante belasting specificeert en visualiseert:
Test Threads
Ook bekend als threads
Dit is het mechanisme dat verantwoordelijk is voor het toepassen van belasting door het gedefinieerde werk in de test uit te voeren, zoals de transacties en/of aanvragen, en deze herhaaldelijk uit te voeren.
Testthreads gedragen zich doorgaans serieel waarbij elke thread begint met het lezen van de eerste aanvraag die in de test is gedefinieerd, deze naar de server stuurt en vervolgens wacht op de reactie. De volgende aanvraag in de test wordt pas uitgevoerd nadat er antwoord is gekomen van de server of nadat er een time-out is verstreken. Zodra aan één van deze voorwaarden is voldaan, gaat hij door naar de volgende aanvraag. De meeste tests zijn zo geconfigureerd dat elke testthread dit proces continu herhaalt gedurende de looptijd.
Verschillende technologieën verwijzen vaak naar testthreads als virtuele gebruikers, maar dit kan misleidend zijn. De testthreads van een test zijn slechts het middel (druk) naar een doel (geleverde doorvoer).
Met andere woorden, het uitvoeren van een test die is geconfigureerd met stapbelasting die 100 testthreads bereikt betekent niet dat de omgeving 100 gelijktijdige virtuele gebruikers ondersteunt. In dit geval zou het aantal gebruikers worden berekend op basis van de doorvoer van de test; transacties/sec bijvoorbeeld.
Apache JMeter Thread Group (bzm - Concurrency) die de stapbelasting definieert via (test) threads:
Gebruikers
Ook bekend als virtuele gebruikers
Het aantal ondersteunde gebruikers is één van de meest gevraagde items om te bepalen vanuit een loadtest en neemt meestal de vorm aan van:
- Hoeveel gebruikers zal deze specifieke service of applicatie ondersteunen?
- Zal een bepaalde service of applicatie ten minste X gebruikers ondersteunen?
De berekening van gebruikers is nauw verbonden met think time evenals gemeten testartefacten zoals doorvoer en reactietijd.
Het gebruik van Little Law met deze invoer kan een theoretische schatting geven van het aantal gebruikers dat een omgeving kan ondersteunen.<\/P>
Denk Tijd<\/STRONG>
Ook bekend als workflow pacing<\/STRONG><\/EM><\/H5>Denk tijd is een duur (gedefinieerd als seconden of milliseconden) die aan een test wordt toegevoegd om de vertragingen van menselijk gedrag te simuleren die zouden optreden wanneer een persoon op natuurlijke wijze met de map service of webapplicatie interacteert.
Denk tijd vertragingen kunnen worden toegevoegd aan transacties (bijv. een operatie) of verzoeken of zelfs aan de test zelf (wat dan workflow pacing wordt genoemd). Hoe ze worden toegevoegd kan variëren afhankelijk van het gebruikte testframework.
In het geval van Apache JMeter zijn er verschillende timers beschikbaar die aan de test kunnen worden toegevoegd om verschillende soorten vertragingen te simuleren.<\/P>Kernprestatie-indicatoren (KPIs)<\/STRONG><\/H5>KPIs zijn teststatistieken die helpen bij de analyse van een load test. Sommige van de populairste zijn gerelateerd aan het meten van de reactietijd en doorvoer van de test. Ze omvatten echter ook items die het aantal mislukte verzoeken tellen, het gemiddelde inhoudslengte (per verzoek) tellen of informatie verzamelen over hardwaregebruik (zoals CPU, geheugen, netwerk en schijf).
Hoewel het vastleggen van hardwaregebruik vaak extra testconfiguratie en permissies binnen de omgeving vereist, is deze informatie een van de belangrijkste artefacten die uit een load test worden verzameld.<\/P>Opmerking: Vastgelegde hardwaregebruik is een van de belangrijkste artefacten die uit een load test worden verzameld.<\/FONT><\/STRONG><\/P>Reactietijd<\/STRONG><\/H5>Reactietijd is een veelgebruikte metriek die wordt gebruikt om de prestaties van een verzoek, transactie of test te meten. Simpel gezegd geeft het inzicht in hoe snel een operatie zich gedraagt.
De waarde wordt meestal weergegeven in seconden of milliseconden. Snellere prestaties betekenen lagere reactietijden wat vertaalt naar een gunstigere gebruikerservaring. Reactietijd kan worden uitgezet over de duur van de test om te begrijpen hoe de prestaties schaalden of samen met doorvoer voor een bepaald punt in de test (bijv. waar doorvoer piekte).<\/P>Opmerking: Reactietijden zijn een van de belangrijkste artefacten die uit een load test worden verzameld.<\/STRONG><\/FONT><\/P>Idealiter zal de prestatie van het geteste item de volgende curve aannemen waarbij de reactietijden sneller zullen stijgen (rond het punt van piekdoorvoer). In het volgende voorbeeld was de gemiddelde reactietijd per verzoek bij piekdoorvoer ongeveer 0,4 seconden.<\/P>
<\/span><\/P>Doorvoer<\/STRONG>:<\/H5>Doorvoer is een veelgebruikte metriek die wordt gebruikt om de schaalbaarheid van een map service, webapplicatie of hardware-infrastructuur te meten. Het geeft in wezen inzicht in het tempo waarmee een operatie kan worden uitgevoerd over een bepaalde tijdsduur.
De waarde kan meestal worden vastgelegd als verzoeken/sec, transacties/sec (bijv. operaties/sec) of tests/sec, hoewel het vaak wordt uitgedrukt over de duur van een uur (het tempo in seconden vermenigvuldigd met 3600).
Hogere schaalbaarheid betekent meer doorvoer wat vertaalt naar ondersteuning voor meer gebruikers.
Sommige testanalyses richten zich op de gemiddelde doorvoer van alle transacties voor een test, terwijl anderen mogelijk de gemiddelde doorvoer voor elke afzonderlijke operatie onderzoeken.<\/P>Opmerking: Doorvoer is een van de belangrijkste artefacten die uit een load test worden verzameld.<\/STRONG><\/FONT><\/P>Idealiter zal de doorvoer van het geteste item lijken op de volgende curve waarbij deze een piek bereikt en vervolgens afvlakt. <\/SPAN>Wanneer doorvoer piekt en/of afvlakt suggereert dit dat de test ergens tegen een bottleneck aanloopt. In het volgende voorbeeld was de gemiddelde verzoekdoorvoer bij piek ongeveer 24 verzoeken/seconde (of 86.400 verzoeken/uur).<\/P>
<\/span><\/P>Bottleneck<\/STRONG><\/H5>Een bottleneck is een toestand binnen een deployment waarbij één van zijn componenten of lagen het tempo beperkt waarmee het kan reageren op binnenkomende verzoeken. Een bottleneck kan zich voordoen in de vorm van:<\/P>Hardware VoorbeeldenAlle CPU-kernen van ArcGIS Server zijn volledig benut<\/LI>Beschikbaar geheugen is uitgeput<\/LI>Opslagschijf I/O van de Database server is volledig benut<\/LI>Netwerkkaart is verzadigdDoor verzonden of ontvangen verkeer <\/LI><\/UL><\/LI><\/UL><\/LI>Software VoorbeeldenDe database was geconfigureerd om slechts 25 gelijktijdige verbindingen toe te staan ondanks dat er voldoende hardwarebronnen beschikbaar waren<\/LI>Doorvoer voor het consumeren van een map service vlakt af maar ArcGIS Server CPU-gebruik stijgt niet boven 25%<\/LI><\/UL><\/LI><\/UL>Er zal altijd een bottleneck bestaan in een deployment en bepalen welk component als eerste beperkt wordt maakt deel uit van de analyse. Het zal vaak een load test vergen om bloot te leggen waar de eerste bottleneck zal optreden omdat dit mogelijk alleen onder grote druk wordt waargenomen. Hoewel serverbronnen en instellingen doorgaans centraal staan bij bottleneck-analyse, kunnen ook testclientbronnen (CPU, geheugen, netwerk, schijf en in sommige gevallen de testing license) een factor zijn. Het bereiken van een bottleneck is niet per se problematisch, het laat je gewoon weten waar de eerste zwakte of beperking binnen het systeem zit. Soms wordt een bottleneck als iets "goeds" beschouwd, bijvoorbeeld bij het uitvoeren van een groot ArcGIS caching-proces, waarbij gewenst is dat de CPU als eerste bottleneck optreedt omdat deze het werk doet om kaarttegels te creëren. Als de CPU slechts tot 50% kan komen vanwege een andere bottleneck (bijv. schijf I/O), duurt het twee keer zo lang voordat het werk klaar is ten opzichte van 100% CPU-gebruik.<\/P>Opmerking: Er bestaat altijd een bottleneck in een deployment<\/STRONG><\/FONT><\/P>Testtype<\/STRONG>
Ook bekend als performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>Veel organisaties gebruiken vaak verschillende categorieën om het uitgevoerde testen te classificeren.<\/P>Een performance test wordt typisch gebruikt om problemen met een service of applicatie op te sporen wanneer deze traag reageert of langere dan verwachte reactietijden produceert. Ze hoeven geen step load te bevatten en kunnen eenvoudig worden uitgevoerd als één gebruiker die direct vanuit een webbrowser met het betreffende eindpunt interacteert.<\/P>Een load test kan vaak worden gebruikt om een step load test te beschrijven met als doel het behalen van specifieke doorvoer- en reactietijddoelen. Bijvoorbeeld X transacties/sec<\/EM> met een reactietijd onder Y seconden<\/EM> en zonder fouten. Dit kan resulteren in uitputting van één van de serverhardwarebronnen maar dat is meestal niet het doel. Een load test kan ook worden aangeduid als schaalbaarheidstest.<\/P>Een stress test is vergelijkbaar maar richt zich vaak op het bereiken van druk die meerdere malen hoger ligt dan het doel van de load test. Met andere woorden, als de load test probeerde X transacties/sec<\/EM> te bereiken, probeert de stress test mogelijk X * 5 transacties/sec<\/EM> te bereiken zonder significante fouten te ondervinden.<\/P>Een endurance test heeft als kenmerk dat deze probeert componenten van het systeem kapot te maken. De toegepaste belasting kan meerdere malen hoger zijn dan die bij stress tests waarbij het doel is significante fouten te ervaren en doorvoer en reactietijd waar te nemen wanneer deze optreden. Een endurance test kan ook duurzaamheidstest worden genoemd waarbij de toegepaste belasting constant is gedurende zeer lange tijd en hardwaregebruik en herstelpatronen worden geobserveerd.<\/P>Testplan<\/STRONG><\/H5>In algemene zin is een testplan document, tabel of lijst die de specifieke tests definieert die zullen worden uitgevoerd, evenals hun respectieve doelen. Deze doelen zijn de reden en het doel van elke test. De analyse van de resultaten (met de hand of uit gegenereerde testrapporten) zou u moeten helpen bepalen of de doelen van elke test zijn bereikt.<\/P>Test Framework <\/STRONG><\/H5>Het test framework is het hulpmiddel of de technologie die wordt gebruikt in de vorm van bibliotheken, API's evenals een grafische gebruikersinterface (GUI) voor het samenstellen van verzoeken, en de test evenals het definiëren van de toe te passen belasting.
Er zijn veel geweldige test frameworks beschikbaar en Apache JMeter is er slechts een<\/EM> van. Hoewel ze allemaal een vergelijkbaar doel hebben, hanteren velen verschillende benaderingen voor de terminologie van bepaalde componenten en hoe ze een test creëren en belasting toepassen. Sommigen plaatsen de definitie van de verzoeken en transacties in hun eigen bestanden met de stapbelastingconfiguratie in een ander.
Met Apache JMeter worden alle testobjecten gedefinieerd in het Test Plan en logisch gescheiden binnen de boomstructuur.<\/P>Enkele voorbeelden van load testing frameworks:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Enkele voorbeelden van performance testing frameworks:<\/P>
wget<\/A>- Een opdrachtregeltool voor het ophalen van één of meer URL's<\/LI>
- Kan een hoog detailniveau bieden over elk verzoek en antwoord<\/LI><\/UL><\/LI>
curl<\/A>
- Een opdrachtregeltool voor het ophalen van één of meer URL's<\/LI>
- Kan een hoog detailniveau bieden over elk verzoek en antwoord<\/LI><\/UL><\/LI>
Fiddler<\/A>- GUI-gebaseerde HTTP Debugger die alleen of met een webbrowser kan worden gebruikt<\/LI>
- Kan een hoog detailniveau bieden over elk verzoek en antwoord<\/LI><\/UL><\/LI><\/UL>
Architectuur Test Framework<\/STRONG><\/H5>Bij het testen van ArcGIS Enterprise richt de meeste architecturale aandacht zich op de schaalbaarheid van de implementatielagen: Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase en Netwerkopslag. Terwijl één 8 Core testmachine meestal een behoorlijk aantal verzoeken kan verzenden die voldoen aan de typische test, zijn soms meerdere machines nodig als de toe te passen belasting serieuze rekenkracht vereist.<\/P>Afhankelijk van het betrokken test framework kunnen verschillende testcomponenten worden gescheiden naar verschillende machines om de schaalbaarheid van de test client<\/EM> te verbeteren.<\/P>Veelvoorkomende componenten om uit te breiden zijn:<\/P>Test ControllerZoals de naam al aangeeft is de hoofdfocus van de controller het starten en stoppen van de test evenals het coördineren van het verzamelen van teststatistieken van één of meer Test Agents<\/LI>In het geval van Apache JMeter is de controller geïntegreerd in de GUI maar draait ook wanneer de test vanaf de opdrachtregel wordt uitgevoerdAndere test frameworks kunnen een webgebaseerde Test Controller frontend hebben<\/LI><\/UL><\/LI>Meestal is slechts één Test Controller nodig voor een gegeven testomgeving, maar deze kan draaien op dedicated hardware die gescheiden is van de Test Agents<\/LI><\/UL><\/LI>Test AgentDe primaire taak van de Test Agent is het verzenden van verzoeken en ontvangen van antwoorden van de serverDeze component voert het meeste werk uit en vereist waarschijnlijk de meeste CPU-bronnen<\/LI><\/UL><\/LI>Voor grote taken kunnen meerdere Test Agent machines nodig zijn<\/LI>In het geval van Apache JMeter draait standaard de Test Agent op dezelfde machine als de Test Controller <\/LI><\/UL><\/LI>Test RepositoryEen machine die is toegewijd aan het opslaan van load testresultaten Dit kan teststatistieken bevatten zoals responstijd, doorvoer en hardwaregebruik<\/LI><\/UL><\/LI>In het geval van Apache JMeter worden de resultaten opgeslagen op de controller in tekst (*.JTL) bestandenHet is mogelijk om resultaten naar een database te sturen, maar dit is niet standaard<\/LI><\/UL><\/LI><\/UL><\/LI>Test VisualisatieEen machine die wordt gebruikt om teststatistieken en hardwaregebruik realtime te visualiseren<\/LI>In het geval van Apache JMeter wordt GUI niet aanbevolen voor datavisualisatie bij een productie testrun maar wel via opdrachtregelAls resultaten naar een database worden gestuurd, kan extra software verbinding maken met Test Repository om informatie te visualiseren<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Interactive Response Time Law<\/STRONG><\/H5>De Interactive Response Time Law is een formule die de relatie definieert tussen belangrijke prestatiefactoren, namelijk gebruikers, doorvoer, responstijd en gebruikersdenk tijd. De berekening kan worden herschikt om de parameter van belang te bepalen zolang u er drie kent. Als bijvoorbeeld het aantal gebruikers dat het systeem gebruikt bekend is, wat de gemiddelde responstijd is voor verzoeken, en wat de gemiddelde gebruikersdenk tijd is, kunnen we vervolgens de geschatte doorvoervraag op het systeem afleiden. Deze wet is zeer nuttig bij pogingen om gebruikers om te zetten naar doorvoer en doorvoer naar gebruikers en andere gebruiksscenario's en vormt een basis voor gebieden gerelateerd aan testen zoals capaciteitsplanning.<\/P>Gegeven onderstaande formule:
N = X * (R + Z)
N = Aantal taken of gelijktijdige gebruikers
X = Doorvoer per seconde in het systeem
R = Responstijd, of gemiddelde tijd die een taak in het systeem doorbrengt
Z = Denk tijdVoor meer informatie over Interactive Response Time Law zie:
http:\/downloads.esri.com\Support\downloads\other_\ArcGIS%20Enterprise%20deployment%20guide_Scene%20layer%20benchmark%20testing.pdfhttps:\/homepages.inf.ed.ac.uk\jeh\biss2013\Note2.pdf< /ul > < /p > < /p >Apache JMeter uitgebracht onder de < /span >Apache < /span >License 2.0.< /a > Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation.< /span >< /p >
