Aanbevolen strategieën voor load testing van een ArcGIS Server-implementatie
De meeste testsoftware kan een soort rapport genereren zodra de test is voltooid. Dit rapport zou de vragen moeten beantwoorden die het testplan stelde.
Bijvoorbeeld:
a) Kon de ArcGIS-service alle CPU gebruiken (bijv. CPU-bound)?
b) Kon de ArcGIS-service een specifieke doorvoer leveren (bijv. een bepaald aantal transacties/sec)?
c) Leverde de doorvoer een gemiddelde responstijd die voldeed aan onze prestatie-eis?
Het definiëren van een doel voor een test helpt om de testinspanning te richten op een doel.
- Tests moeten worden uitgevoerd tegen applicaties zonder bekende grote bugs of defecten
Load testing mag niet worden gebruikt om functioneel een implementatie of applicatie te testen.
Een applicatie moet kwaliteitsborging (QA) testen doorstaan voordat load tests worden uitgevoerd.
Bovendien, als een applicatie grote bugs bevat, kunnen dergelijke tekortkomingen een meetbare impact hebben op de prestaties en schaalbaarheid van de aangeboden services. Dit zou op zijn beurt waarschijnlijk de resultaten van de test tenietdoen en mogelijk tijd, geld en middelen verspillen.
- Interageer met uw applicatie (en ArcGIS-services) voordat u ze load test
Als u de enige gebruiker bent op uw systeem en de ArcGIS-services reageren zeer traag, is er geen reden om een test onder belasting uit te voeren. De volgende stap zou moeten zijn om de ArcGIS-services af te stemmen en te optimaliseren voor prestaties.
- Coördineer testuitvoering
Vaak wordt een load test uitgevoerd in een QA/Staging of Testomgeving, maar soms kan dit ook in Productie gebeuren.
Welke omgeving ook, het is belangrijk te onthouden dat vaak services en middelen ook door andere gebruikers worden gebruikt (en niet alleen door het load testing team).
Om verwarring en onverwachte ervaringen te voorkomen, wordt sterk aanbevolen om de uitvoering van load tests af te stemmen met het juiste personeel.
Dit kan helpen om een betere ervaring te bieden voor daadwerkelijke gebruikers en ongewenste ruis in een load test vermijden (door acties die echte gebruikers mogelijk uitvoeren).
- Verifieer dat de Testomgeving aan de verwachtingen voldoet
Soms kan de Testomgeving vanwege verschillende redenen worden teruggeschroefd. Na verloop van tijd kunnen Test en Productie dan sterk verschillende omgevingen worden. In dat geval zouden testresultaten afkomstig uit Test weinig betekenis hebben in relatie tot hoe Productie zal presteren of schalen.
Bijvoorbeeld:
a) Als Productie wordt verwacht te worden ingezet met een Highly Available architectuur, dan zou Test dat ook moeten zijn
b) Als Productie verwacht wordt gebruik te maken van een enterprise geodatabase met 500GB vectorgegevens, dan zou Test dat ook moeten zijn
c) Als Productie ArcGIS Servers gebruikt met 32 cores en service instance maximums zijn ingesteld op 32, dan zou Test dat ook moeten zijn
Het in lock-step houden van Test en Productieomgevingen kan helpen om de beste waarde (en verwachting) van de resultaten te bieden. In gevallen waar ze bewust niet overeenkomen, maak hiervan dan aantekening voordat het testen begint en in alle afgeleide conclusies over de Testomgeving.
- Begin een load test bij stap 1
Het gebruik van 1 als initiële belastingsstap kan uw post-test analyse ondersteunen.
Stap 1 (of één gelijktijdige testthread) vertegenwoordigt het best mogelijke scenario voor uw test. Dit is uw basislijn en is een goede meetlat om te begrijpen hoe goed of slecht de ArcGIS-service schaalt naarmate de druk toeneemt (bijv. wanneer extra testthreads werden toegevoegd).
- Verzamel hardwaregebruik van alle machines die bij de test betrokken zijn
De meeste testframeworks bieden doorgaans de mogelijkheid om hardwaregebruik te verzamelen van zowel de servers als de testclient zelf. Dit kan waardevol zijn voor het begrijpen van resourceverbruik en het identificeren van knelpunten (bijv. de resources op de testclient kunnen ook een beperkende factor zijn).
Echter, ondanks dat deze functie in de testsoftware aanwezig is, is het verzamelen van hardwaregebruik niet altijd mogelijk vanwege permissies of netwerktoegang (bijv. verbinding maken via firewalls/routers).
Hoewel het verkrijgen van deze informatie direct via een testframework zeker handig is, zijn er andere manieren om deze taak uit te voeren. Het gebruik van gratis tools zoals PerfMon in Windows of dtstat in Linux om deze gegevens vast te leggen is een extra stap maar waard om te doen. Zodra de test is voltooid, kan analyse nog steeds worden uitgevoerd op handmatig gemaakte grafiekgegevens van het hardwaregebruik.
- Test eerst individuele ArcGIS-services
Als een specifieke webapplicatie meer dan één ArcGIS-service gebruikt, test en stem dan elke service afzonderlijk af.
Deze aanpak maakt het gemakkelijker om te identificeren welke services knelpunten of beperkingen hebben die voorkomen dat ze de beschikbare hardware volledig benutten.
Als een ArcGIS-service niet alle beschikbare CPU-hardware van ArcGIS Server kan gebruiken, moet de tester/analist de juiste persoon informeren dat er een afstemmingsmogelijkheid bestaat in de implementatie
Vermijd ook om met het volledige applicatieworkflow te beginnen bij het testen omdat het moeilijk kan zijn potentiële knelpunten te herkennen wanneer veel ArcGIS-services tegelijk worden getest.
- Test zo fysiek dicht mogelijk bij de implementatie
Probeer niet dat de test "de Internet simuleert." Testen zo fysiek dicht mogelijk bij de implementatie kan helpen om het beste inzicht te geven in wat de serverhardware kan leveren.
Het opzettelijk introduceren van netwerkvertraging of slechte bandbreedte zal ruis toevoegen aan een test en het moeilijk maken om het volledige vermogen van de ArcGIS-services en de servers waarop ze draaien te herkennen.
Tests hoeven niet 8 uur te duren om nuttige informatie over de betreffende ArcGIS-service te bieden. Het wordt echter ook aanbevolen om geen te korte loadtest uit te voeren. Het komt neer op het kiezen van een testduur (en duur per stap) die voldoende informatie biedt. Met andere woorden, het gaat erom genoeg aanvraagmonsters vast te leggen om een "goede" gemiddelde waarde te krijgen.
De duur die wordt gebruikt is meestal gekoppeld aan uw responstijd: een snelle responstijd kan veel aanvragen leveren met een stappenbelasting van 5 minuten. Een trage responstijd heeft mogelijk een stappenbelasting van 15 minuten nodig om evenveel waarden vast te leggen.
Als tester krijgt u misschien niet altijd meteen stap- en testduur goed ingeschat en moet u mogelijk aanpassen en opnieuw testen.
- Wees bewust van het ArcGIS Server Log Level
Hoewel de ArcGIS Server-logboeken veel informatie kunnen bieden voor analyse, is het belangrijk te begrijpen dat hogere logniveaus zoals VERBOSE en DEBUG de prestaties van een zeer drukke site kunnen vertragen en geen aanbevolen instelling zijn voor een productieomgeving. Daarentegen biedt WARNING (de standaardwaarde) de best mogelijke serviceprestaties omdat alleen waarschuwingen en fouten worden geregistreerd.
Een instelling FINE is echter een goede compromis tussen nuttige analytische informatie (zoals verstreken tijden bij dynamische aanvragen) en snelheid.
- Traditionele ArcGIS-services kunnen binnen (ArcGIS) Server worden afgestemd
Voordat u load testing uitvoert op een traditionele (bijv. dedicated) ArcGIS-service om deze af te stemmen of om te begrijpen hoe deze presteert, probeer dan eerst de waarde van zijn ArcSOC instance maximum in te stellen op het aantal beschikbare CPU-kernen op ArcGIS server.
Na het herstarten van de service zal deze instelling meerdere gelijktijdige aanvragen toestaan om optimaal gebruik te maken van de beschikbare hardware en deze in het beste licht tonen (ervan uitgaande dat de service CPU-bound is).
style="padding-left : 30px;">Het verhogen van de maximale waarde van de ArcSOC-instantie zal ook toestaan dat de service meer CPU gebruikt, maar daardoor ook meer geheugen. Zorg ervoor dat er voldoende geheugen beschikbaar is op de ArcGIS Server-machine om de aanpassing te accommoderen. Als de service niet zwaar wordt gevraagd, worden de extra instanties inactief (standaard is 1800 seconden) en worden ze afgesloten om servergeheugen vrij te maken.<\/P>
Evenzo is het verhogen van het minimum van een service-instantie (om overeen te komen met het maximum) een goede strategie om voorspelbare prestaties te verkrijgen. Dit wordt aanbevolen voor de populairste services, maar houd er rekening mee dat een dergelijke configuratie altijd geheugen zal gebruiken (voor die service) omdat geen instanties worden afgesloten nadat de inactieve tijd is verstreken.<\/P>
Gedeelde services hebben ook instantie-instellingen die kunnen worden aangepast. Echter, als een gedeelde service populair genoeg is om load testing te ondergaan, moet deze worden aangepast om als een traditionele, toegewijde service te draaien.<\/P>
- Niet alle ArcGIS-services zijn CPU-bound<\/STRONG><\/LI><\/UL>Als een ArcGIS-service CPU-bound is, betekent dit dat de hoeveelheid doorvoer die het kan leveren (of capaciteit die het kan ondersteunen) alleen wordt beperkt door het aantal CPU's op de ArcGIS Server-machine(s). In veel opzichten kan dit een goede zaak zijn.<\/P>Dit is echter niet altijd het geval. Soms kunnen er knelpunten zijn in andere hardware zoals het netwerk, bijvoorbeeld. Af en toe kunt u een knelpunt tegenkomen in een softwarecomponent die opzettelijk of onbedoeld kan zijn.<\/P>Daarom is het verzamelen van hardware-metrics tijdens de test erg belangrijk. Het observeren van het gebruik van CPU, Geheugen, Netwerk en Schijf kan de tester\/analist essentiële informatie geven om te begrijpen of er iets is dat de schaalbaarheid van de ArcGIS Server-service beperkt en of dit aan de hardware van de server of van de testclient ligt.<\/P>Het draait allemaal om doorvoer (niet gebruikers)<\/STRONG><\/LI><\/UL>Doorvoer wordt gemeten, gebruikers worden berekend... het zijn twee verschillende artefacten uit een test.<\/P>In een test wordt doorvoer meestal gedefinieerd als transacties per seconde (of operaties per seconde), en dit is een waarde die gemeten moet worden door de testclient-software. Aan de andere kant kan de definitie van een "gebruiker" variëren maar wordt meestal berekend op basis van doorvoer.<\/P>Omdat doorvoer direct wordt waargenomen uit de resultaten van een load test, is het een van de beste metrics om de schaalbaarheid van een implementatie te bepalen.<\/P>In verband hiermee is een testthread (bijv. het item dat toeneemt naarmate er meer druk wordt toegevoegd aan een load test) ook niet hetzelfde als een gebruiker. Het aantal gebruikte testthreads en hun duur worden meestal geconfigureerd in de step load-definitie van een test.<\/P>Verifieer dat de test succesvol was<\/STRONG><\/LI><\/UL>Het voltooien van een test betekent niet noodzakelijk dat deze "goed" was en in staat was om succesvol de vragen in het testplan te beantwoorden. Het is belangrijk om te verifiëren en valideren dat de test de juiste verzoeken stuurde waar dat moest en de verwachte antwoorden kreeg.<\/P>Een snelle handmatige kwaliteitscontrole (QC) check van de samenstelling van verzoeken in de test kan helpen bij het eerste.<\/P>Het monitoren van de gemiddelde inhoudslengte (per antwoord) kan helpen bij het laatste.<\/P>De meeste testsoftware biedt een "waarom" om de gemiddelde inhoudslengte (of iets dergelijks) vast te leggen. De algemene vuistregel is dat de gemiddelde waarde voor deze metric relatief constant moet blijven gedurende de test. Als deze drastisch stijgt of daalt, wordt verder onderzoek aanbevolen omdat het verwachte antwoord voor de verzoeken mogelijk niet terugkomt (bijv. fouten in plaats van afbeelding of json-inhoud) of als het antwoord geldig maar sterk variabel is, kan een ander testontwerp nodig zijn.<\/P>Daarnaast is het belangrijk om te bepalen of de verzoeken zelf succesvol waren (bijv. HTTP 200). Sommige testsoftware stelt analisten in staat validatiecontroles op antwoorden binnen de test zelf te configureren. Dat gezegd hebbende, geeft het profileren van de gemiddelde inhoudslengte-metric meestal een nauwkeuriger beeld van het verwachte antwoord van de server.<\/P>Testresultaten zijn geen garantie voor ondersteuning van X aantal gebruikers<\/STRONG><\/LI><\/UL>Testresultaten valideren alleen de geteste workflow. Deze geteste workflow toont doorvoer voor een specifiek type verzoek met bijbehorende responstijd. Het belooft of garandeert niet dat de implementatie X aantal gebruikers zal ondersteunen.<\/P>Onthoud dat de definitie van een gebruiker kan variëren en verschillende betekenissen kan hebben voor verschillende implementaties.<\/P>Vermijd testen van gedeelde bronnen zoals ArcGIS Online of Google Maps<\/STRONG><\/LI><\/UL>Gratis en openbare service-aanbiedingen van ArcGIS Online of Google Maps zijn er voor de "community". Dergelijke bronnen zijn behoorlijk robuust en schaalbaar maar kunnen niet prestatiegericht worden afgestemd voor elke gebruiker.<\/P>Aangezien ze geen direct onderdeel zijn van een on-premise implementatie, moeten ze als "externe" bronnen worden beschouwd. Daarom moeten verzoeken aan hen uit een load test worden verwijderd omdat de test zich uitsluitend moet richten op de mogelijkheden van eigen hardware.<\/P>Herhaalbare testresultaten<\/STRONG><\/LI><\/UL>Als resultaten voor een load test tegen een ArcGIS Server-service vergelijkbare trendlijnen tonen over meerdere testruns (bijv. dezelfde doorvoer wordt bereikt rond hetzelfde punt tijdens de test), wordt deze bron over het algemeen als "stabiel" beschouwd. Het kunnen herhalen van resultaten voor een test is een goede eigenschap.<\/P>Wanneer resultaten niet onmiddellijk herhaalbaar zijn, moet de tester\/analist dieper kijken en proberen het inconsistente gedrag te begrijpen. Het kan zijn dat de hardware werd gebruikt om andere verzoeken dan die van de test te bedienen (bijv. een andere gebruiker op het systeem). Of als de implementatie op gedeelde infrastructuur was (bijv. virtualisatie), werd onderliggende hardware gebruikt voor andere doeleinden (andere virtuele machines voerden resource-intensieve taken uit). In dergelijke gevallen kunnen load tests buiten piekuren meer reproduceerbare resultaten opleveren die aantonen dat de service potentieel stabiel is.<\/P>Ontwerp tests\/workflows realistisch en gebaseerd op wat verwacht zou worden van een gebruiker<\/STRONG><\/LI><\/UL>Vermijd theorieën en projecties; concentreer je gewoon op hoe de gebruiker zou moeten werken met de applicatie...de verwachte workflow.
Load testing kan eenvoudig zijn maar ook gemakkelijk uitgebreid worden naar onnodige of onwaarschijnlijke scenario's.<\/P>Begrijp de waarde<\/STRONG><\/LI><\/UL>Vaak is het pad naar een goede en nuttige test net zo belangrijk als de test zelf. Als analist helpt dit je:<\/P>a) De testprocedures valideren<\/P>b) De grootste mogelijkheid hebben om resultaten uit te leggen wat jouw test waardevol maakt<\/P> 1) Sommige personen zullen niet alleen om resultaten vragen maar ook om analyse en conclusies<\/P> 2) Wees voorbereid deze conclusies met data te onderbouwen<\/P>Houd het simpel<\/STRONG><\/LI><\/UL>Soms zijn eenvoudige tests inspanningen het meest informatief en niet overdreven complex.<\/P>
