Voorbereiden op de overstroming: Zal uw GIS Server zinken of zwemmen?

RandallWilliams

<\/HEAD>Ik heb onlangs wat load testing gedaan tegen ArcGIS Server, en het kwam bij me op dat hoewel we gebruikers vaak aanraden om load testing tools te gebruiken voordat ze een GIS-applicatie openbaar maken, we niet al te veel in detail treden over hoe je die tests moet opzetten. In deze blog zal ik beschrijven hoe je tests configureert en uitvoert met behulp van een open source Java-tool genaamd JMeter om te helpen bij het load testen van je GIS Server-installatie en applicatie.Allereerst, wat is JMeter<\/A>?<\/STRONG>

Van de JMeter-website:

10 Apache JMeter<\/STRONG>17 desktopapplicatie is open source software, een 100% pure Java-applicatie ontworpen om functioneel gedrag te load testen en prestaties te meten. Het was oorspronkelijk ontworpen voor het testen van webapplicaties maar is sindsdien uitgebreid naar andere testfuncties. 10 Wat kan ik ermee doen? <\/STRONG>

10 Apache JMeter kan worden gebruikt om prestaties te testen op zowel statische als dynamische bronnen (bestanden, Servlets, Perl-scripts, Java-objecten, databases en queries, FTP-servers en meer). Het kan worden gebruikt om een zware belasting op een server, netwerk of object te simuleren om de sterkte te testen of om de algehele prestaties onder verschillende belastingssoorten te analyseren. Je kunt het gebruiken om een grafische analyse van prestaties te maken of om het gedrag van je server\/script\/object onder zware gelijktijdige belasting te testen."

Dat is allemaal geweldig, maar hier is wat ik<\/STRONG> ermee doe:

Ik gebruik JMeter om de belasting van een groep gebruikers die gelijktijdig met ArcGIS Server werken te simuleren. Deze gesimuleerde gebruikers zijn SUPERHUMAN, want mijn JMeter-tests sturen verzoeken af met een snelheid van honderden of duizenden per minuut. Onlangs heb ik het geheugengebruik van 10.1 getest na letterlijk meer dan 100 miljoen query feature-verzoeken naar ArcGIS Server op een AMI gedurende ongeveer een week. (Je zult blij zijn te weten dat ik ontdekte dat het geheugen tijdens deze test goed werd beheerd).

Onthoud dat JMeter geen browser is. Terwijl de server elke operatie die je indient zal voltooien, zal JMeter de respons niet grafisch weergeven. Je krijgt resultaten in de vorm van een PASS\/FAIL-melding.

Mooi. Laten we dat samenstellen en een test uitvoeren. Laat me je erdoorheen leiden.Wat heb ik nodig?<\/STRONG>

Goede vraag. Je hebt nodig:Je ArcGIS Server-machine. Je kunt Java of .Net testen, op elk ondersteund besturingssysteem.<\/LI>Een plek om JMeter te installeren. Dit kan dezelfde machine zijn als je ArcGIS Server, maar ik vind dat je nauwkeurigere resultaten krijgt als JMeter ergens anders is geïnstalleerd. Dat komt omdat tijdens het draaien de Java-container van de JMeter-applicatie behoorlijk wat RAM zal gebruiken, wat je resultaten kan vertekenen. JMeter is een pure Java-tool, dus het kan draaien op Windows en Linux. Voor mijn tests draai ik JMeter op Win08.<\/LI>Fiddler en Firebug. Ik vind dat de Fiddler<\/A>-tool handig is voor het oplossen van mislukte verzoeken en dergelijke. Het is ook goed voor het helpen bouwen van verzoeken die in je testplan worden gebruikt. Fiddler en Firebug (add-on voor de Firefox-browser) zijn beide uitstekende lichte tools voor testen en debuggen.<\/LI>De Java Runtime Environment (JRE) geïnstalleerd en een omgevingsvariabele die wijst naar JAVA_HOME.<\/LI><\/UL>Waar begin ik?<\/STRONG>

Er is eigenlijk geen installer voor JMeter, alles wat je nodig hebt zit in de applicatiemap. Het eerste wat je moet doen is de JMeterbin-map openen en kijken naar het bestand JMeter.bat.  Op regel 71 vind je de regel die als volgt luidt:set HEAP=-Xms512m \u2013Xmx512m<\/EM>

Deze variabele definieert de hoeveelheid geheugen die aan de Java Heap wordt toegewezen.

Ik zou dit verhogen naar 1024, waarbij ik een volledige gigabyte geheugen toewijs aan de JVM, zo:set HEAP=-Xms1024m -Xmx1024m<\/EM>

Anders loop je vooral bij grotere tests het risico om over de Java Heap-drempel heen te gaan, wat kan veroorzaken dat de JVM die aan JMeter is toegewezen faalt.

Nadat je JMeter hebt gedownload, de JRE hebt geïnstalleerd en de JAVA_HOME-omgevingsvariabele hebt ingesteld die wijst naar je Java-installatielocatie, is het tijd om JMeter op te starten. Open hiervoor een opdrachtprompt en navigeer naar de BIN-directory van JMeter (dezelfde plek waar JMeter.bat staat). Roep JMeter.bat aan vanaf een opdrachtregel en de JMeter-applicatie zal openen.<\/A>

Met JMeter geopend is het tijd om eerst enkele standaardwaarden te defini57ren. Klik hiervoor met rechts op het Test Plan-pictogram (het lijkt op een maatbeker) en voeg een HTTP Request Defaults-element toe.  (Toevoegen>Config Element>HTTP Request Defaults)<\/A>

Nu vullen we enkele van deze parameters in op de HTTP Request Defaults-pagina.

Servernaam of IP: dat spreekt voor zich. Vul het IP-adres of hostnaam in van de machine waarop ArcGIS Server draait (of de proxy die naar server wijst).  Ik definieer meestal geen connectie- of responsetime-outs hier in JMeter. Het pad is het pad naar je SOAP- of REST-eindpunt - naar de operatie die je wilt uitvoeren (query, export map, enz.). De parameters die met het verzoek worden meegestuurd lijken op de parameters die worden gedefinieerd als je via de REST Services Directory queryt.

Ik vind het handig om de Fiddler-tool te gebruiken om de URL's vast te leggen van queries die via de REST-pagina van de service of je webapplicatie worden verzonden ter ondersteuning bij het invullen van deze parameters.

Bijvoorbeeld, je kunt een query uitvoeren gebaseerd op een set X\/_Y-coördinaten met als bedoeling enkele attributen voor een gegeven feature op te halen. In dat geval kun je in Fiddler een URL vastleggen die lijkt op het volgende:

http:\/\/_randall:6080\/_arcgis\/_rest\/_services\/_usa\/_MapServer\/_0\/_query?where=\n&text=&objectIds=&time=&geometry=-119.78861600000%2C35.30318900030\n&geometryType=esriGeometryPoint&inSR=4269&spatialRel=esriSpatialRel\nIntersects&relationParam=&outFields=*&returnGeometry=true&maxAllowable\nOffset=&outSR=&returnIdsOnly=false&returnCountOnly=false&orderByFields\n=&groupByFieldsForStatistics=&outStatistics=&returnZ=false&returnM=false\n&f=pjson<\/PRE>
In deze URL voer ik een query uit naar laag '0' in een service genaamd 'usa' bediend vanaf poort 6080 op een machine genaamd 'randall'.

Ik gebruik geen echte SQL-operatoren (de where-clausule), noch zoek ik naar een specifiek tekstattribuut (text). Ik geef niets om het object-ID of het tijdselement. Ik geef wel om de geometrie, daar zijn mijn XY-waarden gespecificeerd. In feite zijn de enige elementen waar ik in deze test om geef: de ruimtelijke referentie (4326), de ruimtelijke relatie (intersect), de outfields (*, omdat ik ze allemaal wil), en ik stuur de geometrie als punt in. Ten slotte wil ik voor deze test dat de server reageert op mijn verzoeken in JSON-formaat.  Met dat in gedachten kan ik de URL die ik ga parsen iets inkorten om het instellen van de JMeter-test iets beheersbaarder te maken:http:\/localhost:6080\/_ArcGIS\/_rest\/_services\/_usa\/_MapServer\/_0\/_query?&geometry\n=-149.54518800000%2C70.42196900010&geometryType=esriGeometryPoint&inSR=4269\n&spatialRel=esriSpatialRelIntersects&returnCountOnly=false&returnIdsOnly=\nfalse&returnGeometry=true&outFields=*&f=json<\/PRE>
Zodra ik deze standaardwaarden heb verzameld, zet ik deze inputs in mijn JMeter-project:

<\/A>

Vervolgens moet ik enkele gesimuleerde gebruikers instellen. Terwijl we nu de request defaults hebben ingesteld, willen we testen met veel verschillende waarden - met andere woorden, we willen niet dat onze applicatie steeds hetzelfde verzoek verwerkt, dat is te makkelijk. Het is beter als we kunnen testen met veel verschillende samples.  In JMeter wordt dit bereikt door 'thread groups' aan te maken.

Klik met rechts op het testplan en selecteer 'Toevoegen', dan 'Threads (Users)'. In mijn geval simuleren we een belasting van 16 gebruikers, dus elke thread group bevat 2 threads. Ik wil zien hoeveel belasting mijn applicatie aankan voordat hij faalt, dus stel ik deze test in om oneindig door te lopen.<\/A>

Zodra de Thread Groups zijn ingesteld, moeten we ook nog daadwerkelijk requests instellen die zowel de eerder ingestelde defaults bevatten als variabelen die we willen meegeven in onze requests. Klik hiervoor met rechts op een Thread Group; kies 'Toevoegen', 'Config Element', en dan 'HTTP request defaults'. Dit scherm zou bekend moeten voorkomen; het lijkt precies op wat we oorspronkelijk hebben gemaakt.

In dit geval is het doel van de test om te zien hoeveel belasting de server aankan als er vele honderden duizenden query-verzoeken worden verzonden om de attributen van een feature te verzamelen op basis van XY-coördinaten die via de query worden doorgegeven.

Dus, voor elk verzoek dat door JMeter wordt verzonden, zal het enige query-element dat van verzoek tot verzoek verandert de invoerpuntgeometrie zijn. Hiervoor heb ik een .CSV-bestand samengesteld en een CSV Data Set Configuration-element ingesteld in mijn testproject (Toevoegen>Config element>CSV data set Config). Je gegevensbron hoeft geen CSV te zijn, je kunt ook een databasetabel gebruiken als je dat liever hebt – gebruik daarvoor een JDBC-verbinding.<\/A>

Volgens de bovenstaande afbeelding heet mijn CSV-bestand xycord.csv (ik heb de CSV opgeslagen in dezelfde map als mijn testplan – als die van jou ergens anders is opgeslagen, stel dan de bestandsnaam in op het absolute pad waar het zich bevindt.

Zorg ervoor dat je de variabelenamen correct instelt – als er spaties en komma's in je CSV-bestand staan; zorg ervoor dat dit element die spaties weerspiegelt. De komma-afbakening hier scheidt alleen variabelenamen in de CSV – de werkelijke scheidingsteken die in het CSV-bestand wordt gebruikt, wordt beschreven in de parameter 'Delimiter'. Omdat ik mijn test laat draaien totdat ik hem stop, recycle ik de verzoeken en stop ik niet wanneer JMeter detecteert dat het einde van het bestand is bereikt.

Voor mijn test heb ik elk HTTP-verzoekparameter gerepliceerd voor elk van de gebruikers die ik simuleer in de threadgroepen die ik heb opgezet.

Nu is het tijd om te testen. Sla het testplan op.

Ga in JMeter naar 'Run', dan 'Start'. Klik op een van de rapporten.

Met wat geluk zullen je verzoeken worden uitgevoerd. Als het foutpercentage dat je krijgt 100% is, dan stuur je waarschijnlijk slechte verzoeken.

Je kunt de verzoeken die je naar de server stuurt onderzoeken door met de Fiddler-tool te werken:

Als Fiddler op dezelfde machine als JMeter is geïnstalleerd, kun je op de hoofd HTTP request defaults-pagina het verkeer via de Fiddler-proxy laten lopen zodat verzoeken en daaropvolgende antwoorden worden vastgelegd. Standaard luistert Fiddler op poort 8888, dus je kunt JMeter als volgt instellen:<\/A>

Wanneer je je JMeter-run opnieuw start, zal Fiddler het verkeer vastleggen, waardoor je kunt zien wat JMeter doorgeeft zodat je aanpassingen kunt maken volgens jouw behoeften.Enkele tips<\/STRONG>

Gebruik zo min mogelijk listeners. Voor kleinere tests zijn de grafische tellers geweldig. Deze tellers gebruiken echter veel geheugen, en ik heb mijn JVM laten crashen bij grotere tests wanneer ik met tellers werkte. Ik gebruik gewoon het Summary Report – dat heeft de informatie die ik nodig heb.

Overweeg om JMeter vanaf een commandoregelinterface te gebruiken zodra je configuratie is ingesteld. De Command Line-optie gebruikt minimaal resources.

Dat was het voor deze aflevering. Ik zal aanvullende testworkflows volgen zodra ik kan.Randall W. - Server Support Analyst<\/EM>



<\/BODY><\/HTML>

AndresCastillo

This is exactly the tool (also SoapUI) that we are using now to load test and debug some datastore crashes we are experiencing.

See related article:

https://community.esri.com/groups/technical-support/blog/2017/01/11/gauging-arcgis-gis-server-performance-with-integrated-windows-authentication 

Also, another tool that we use in case of a request failure:

https://community.esri.com/groups/technical-support/blog/2018/06/07/monitoring-web-service-requests-using-fiddler 

Also, Chrome Dev Tools>Network>export Har