Prestaties: Uitdagingen en Strategieën
ArcGIS Enterprise biedt een robuust en schaalbaar platform voor het leveren van GIS-bronnen aan gebruikers via services en webapplicaties. Soms kunnen implementaties echter trage prestaties ervaren vanaf de gepubliceerde resource-eindpunten.
Aangezien ArcGIS zeer veelzijdig is, kunnen er verschillende manieren, configuraties en opties zijn om deze bronnen beschikbaar te stellen voor gebruik.
Het verkrijgen van goede prestaties is niet altijd zo eenvoudig en rechttoe rechtaan als het simpelweg inschakelen van een "fast = true" instelling.
Wat voor sommige beheerders een handige functie kan zijn, kan een configuratie zijn die, hoewel nuttig, de prestaties voor anderen kan beïnvloeden.
In de praktijk is prestatie vaak een functie van meerdere items en configuratie-instellingen. Het hebben van strategieën om de meest voorkomende te begrijpen en te overwinnen kan helpen om de implementatie op weg te helpen naar snellere prestaties.
Wat is Prestatie?
Prestatie is een beschrijving van hoe snel (of langzaam) een server of service werkt voor een bepaalde functie van belang. Hoe lang het duurt voordat een ArcGIS Server service een bewerking zoals query, applyEdit of export voltooit en vervolgens de reactie terugstuurt naar de client die het heeft aangevraagd, zou een voorbeeld zijn van prestatie.
Deze duur wordt gemeten in seconden of milliseconden en wordt gewoonlijk aangeduid als de responstijd.
Hoewel het "responstijd" wordt genoemd, zijn er verschillende belangrijke stappen die samen de totale tijd vormen die een client zoals een webbrowser of ArcGIS Pro besteedt aan het wachten op een aangevraagde serverresource:
- DNS-opzoeking van de hostnaam van de server
- SSL-handshake tussen client en server
- TCP/IP-verbinding tussen client en server
- Verzenden van het verzoek naar de server
- Server verwerkt het verzoek
- Ontvangen van reactie van server
- Voor grote reacties kan Time-to-first-byte (of TTFB) worden gebruikt om responstijd te meten
Typisch wordt het grootste deel van de tijd besteed aan 4.1. Dit is waar de server aan het werk is met de reactie.
Dit Community-artikel zal gebieden verkennen die dit deel van de responstijd kunnen beïnvloeden.
Waarom is Prestatie Belangrijk?
Simpel gezegd: hoe sneller de prestatie, hoe lager de responstijd.
Hoe lager de responstijd, hoe meer verzoeken de server tegelijkertijd kan ondersteunen.
Deze hogere gelijktijdigheid van verzoeken vertaalt zich in grotere schaalbaarheid wat uiteindelijk betekent ondersteuning voor meer gebruikers.
Prestatie wordt gemeten als een tijdseenheid die nodig is om één enkele bewerking tegelijk te voltooien (bijv. 0,238 seconden om een feature query-verzoek uit te voeren).
Schaalbaarheid daarentegen wordt vaak gemeten als transacties of bewerkingen over tijd (bijv. verzoeken/sec of bewerkingen/uur).
Wanneer we praten over betere, snellere of "meer" prestaties, impliceert dit het bereiken van lagere responstijden. Aan de andere kant impliceert betere schaalbaarheid het bereiken van een hogere doorvoersnelheid (bijv. meer bewerkingen/uur).
Opmerking: Natuurlijk moeten voor het verkrijgen van betere prestaties of doorvoer, de bewerkingen van belang correct worden uitgevoerd en reageren met de verwachte inhoud (bijv. kaartafbeelding, json of pbf-gegevens). Foutmeldingen bijvoorbeeld kunnen een snelle, eenvoudige reactie zijn waarvan de levering een hoge doorvoersnelheid kan bereiken. Als testers en analisten zijn we niet geïnteresseerd in dit soort doorvoer... we zijn geïnteresseerd in de doorvoer van succesvolle verzoeken.
Wat is Acceptabele Prestatie?
Dat hangt ervan af.
De criteria of vereiste om iets te classificeren als snel (of traag) kan sterk variëren per organisatie, de gepubliceerde services en verwachte bewerkingen die gebruikers zullen aanroepen.
Het is niet ongebruikelijk om verschillende responstijddoelen te hebben voor ArcGIS Server-functies of gebruikersapplicatieworkflows (meerdere verzoeken gegroepeerd om één bewerking te vertegenwoordigen).
Ieder aantal seconden is acceptabel als vereiste maar houd er rekening mee dat er mogelijk meer hardware nodig is evenals uitgebreidere tuning en strategieën (dit artikel) om agressieve doelen te bereiken.
Hoe Wordt Prestatie Gemeten?
Responstijd is de belangrijkste maatstaf om te bepalen of prestatie voldoet aan of binnen een streefvereiste blijft.
Veelgebruikte strategieën voor meten zijn:
- Eén gebruiker interactie
- Via de webbrowser of ArcGIS Pro
- Dit is het gemakkelijkste startpunt
- Als er nog geen begrip is over prestatie, begin hier
- Statistische analyse van grote hoeveelheden responstijden
- Via loganalyse tools, de ArcGIS Server Manager Statistics-pagina of andere observability utilities
- Dergelijke benaderingen hebben als voordeel dat ze echte verzoeken analyseren die gebruikers al tegen de implementatie hebben uitgevoerd
- Dit wordt later in het artikel uitgebreider besproken
- Load Testing
- Kan inzicht geven in prestatie en schaalbaarheid
- Tijdrovender om op te zetten
- Online bronnen bestaan om mee te beginnen
Bij het analyseren van logs of uitvoeren van tests is een veelgebruikte strategie om statistieken te gebruiken voor het opsplitsen van grote hoeveelheden responstijden. Het gemiddelde en 90e (of 95e) percentiel, minimum en maximum helpen bij het verkrijgen van inzicht in de prestatie die de gebruiker mogelijk heeft ervaren.
Responstijden Vastleggen -- Webbrowser
Hoe responstijden worden vastgelegd via één gebruiker interactie is een leuk onderwerp voor discussie.
De gemakkelijkste manier om responstijden van REST-verzoeken vanuit een webapplicatie vast te leggen is met behulp van de "developer tools" functionaliteit van de browser. Alle grote browsers bieden enige weergave van verzoeken, reacties en tijden die worden verzonden en ontvangen. Deze duur kan een idee geven hoe snel een verzoek of bewerking (mogelijk meerdere verzoeken) werd uitgevoerd. Er kunnen dan beslissingen worden genomen of dit acceptabel is of verbeterd moet worden.
Responstijden Vastleggen -- ArcGIS Pro
Hoewel ArcGIS Pro ook communiceert met ArcGIS Enterprise via REST, heeft het geen ingebouwde equivalent van developer tools. Voor het vastleggen van responstijden heb je een aparte HTTP-debugger nodig. Er zijn er veel beschikbaar; een populaire keuze is Fiddler.
Met Fiddler geïnstalleerd op dezelfde machine als ArcGIS Pro kan deze worden geconfigureerd om het verkeer te onderscheppen. Verzoekparameters, response-inhoud en tijden kunnen op vergelijkbare wijze worden vastgelegd en onderzocht.
Zijn Doelen Vereist voor Prestatieverbetering?
Zeker niet. GIS-beheerders kunnen altijd analyseren, afstemmen en best practices toepassen op het systeem, zelfs als er geen officiële prestatievereisten zijn vastgesteld.
Het wordt echter sterk aanbevolen om te begrijpen welke prestaties uw systeem aanvankelijk levert (bijv. dit wordt meestal aangeduid als baseline-responstijdcijfers) voordat aanpassingen worden gedaan. Op deze manier kunt u bepalen of de aangebrachte wijzigingen een positief effect hebben.
Veelvoorkomende Prestatie-uitdagingen en Potentiële Strategieën
Service Pool Types and Instances
< DIV >< P >< SPAN > Een van de meest voorkomende gebieden waar ArcGIS-beheerders prestatie-uitdagingen tegenkomen, is het instellen van het juiste aantal instanties voor
dediëerde-services. Maar laten we eerst eens kijken naar de verschillende types.
Er zijn 3 servicetypes, elk met hun eigen sterke punten.</ DIV >< UL >< LI >< STRONG >Dediëerd </ LI >< LI >< STRONG >Gehost </ LI >< LI >< STRONG >Gedeeld </ LI ></ UL >< DIV >< P >Als GIS-beheerder is het belangrijk om het instantie-type te kunnen identificeren voor een service.<\/P>Dit kan eenvoudig worden bekeken binnen ArcGIS Server Manager, onder Manage Services:<\/DIV>
<\/DIV>
<\/span><\/P><\/DIV>Selecteren van het juiste type<\/SPAN><\/H3>Het kiezen van een dedicated servicetype is ideaal wanneer het bereiken van de meeste prestaties en schaalbaarheidscontrole gewenst is<\/U>. Met dit type kan de beheerder:<\/P><\/DIV>Het maximale aantal instanties instellen op het aantal CPU-kernen om volledig gebruik te maken van de beschikbare verwerkingscapaciteit van de ArcGIS Server-machine (via het maximum)<\/SPAN><\/LI>Geheugen besparen wanneer inactief (via het minimum)<\/SPAN><\/LI>Aanpassen voor voorspelbare prestaties door de min en max op dezelfde waarde in te stellen<\/SPAN><\/LI><\/UL>Dedicated services zijn ideaal voor zwaar gevraagde services of services waarbij prestaties cruciaal zijn.<\/P>Hosted services gebruiken geen ArcSOC-instanties en schalen automatisch indien nodig. De ArcGIS-mogelijkheden die beschikbaar zijn voor Hosted zijn echter beperkt, omdat het voornamelijk wordt gebruikt voor feature queries.<\/P>Shared services zijn uitstekend voor toegang tot items die minder vaak worden opgevraagd. Ze hebben doorgaans meer ArcGIS-mogelijkheden beschikbaar, maar niet alle ArcGIS-functionaliteit is beschikbaar (bijv. branch versioning). Een gedeeld instantiepool is het standaardtype bij het publiceren van een service met ArcGIS Pro<\/U>.<\/P>Opmerking: Het is belangrijk om te herhalen dat als het geselecteerde servicetype is ingesteld op dedicated, het (minimum en maximum) aantal instanties moet worden geëvalueerd om ervoor te zorgen dat ze optimaal zijn. De standaardinstelling bij publiceren in ArcGIS Pro is om slechts een maximum van 2 (instanties) te gebruiken. Dit kan te laag en onvoldoende zijn voor services waarbij prestaties/schaalbaarheid belangrijk zijn.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Focus op de Kaart<\/H2>Het optimaliseren van de kaart is geen nieuwe strategie, maar een relatief eenvoudige om te volgen voor betere prestaties van uw implementatie.
Wanneer de kaart gericht is op zijn primaire doel en presentatie, hoeft het systeem geen onnodig werk te doen. Onthoud dat het web een multiuser-platform is. Het zo gestroomlijnd mogelijk maken van de weergave van dynamische data is de sleutel tot goede prestaties (en schaalbaarheid). Met mogelijk veel gelijktijdige verzoeken moet de gedeelde inhoud zo efficiënt mogelijk zijn.<\/P>
<\/span>Kaartstrategieën<\/SPAN><\/H3>Kies een optimale standaarduitbreiding<\/SPAN>Als de kaart gegevens over Los Angeles levert, mag de standaarduitbreiding niet<\/EM> heel Californië tonen<\/LI>Als veel verschillende kaartschaalniveaus vereist zijn, gebruik schaalafhankelijkheden en generalisatie om de details te beperken tot wanneer u ze het meest nodig hebt (bijv. de grootste schalen)<\/LI><\/UL><\/LI>Verwijder onnodige lagenOverweeg het verwijderen van nice-to-have datalagenZet ze op zijn minst uit en laat gebruikers zelf kiezen om ze in te schakelen<\/LI><\/UL><\/LI><\/UL><\/LI>Beperk bewust wat gebruikers met een service kunnen doen<\/LI>Vermijd projectie on-the-flyGebruik hetzelfde coördinatensysteem voor data frame en data<\/LI><\/UL><\/LI>DefinitiequeriesZorg dat indexen aanwezig zijn als vergelijkingslogica wordt toegepast op attribuutkolommen <\/LI><\/UL><\/LI><\/UL>Opmerking: "Focus op de kaart" geldt voor kaarten, apps en services<\/FONT><\/STRONG><\/DIV>Software Releases<\/H2>Een specifieke versie van ArcGIS Enterprise (en gerelateerde oplossingen) kan na de initiële basisrelease een aantal patches hebben. Deze patches kunnen prestatieverbeteringen bieden evenals functionaliteits- en beveiligingsfixes. <\/P>Het wordt sterk aanbevolen om periodiek de Esri Patches and Updates<\/A> site te controleren of de tool "Check for ArcGIS Enterprise Updates" uit te voeren. Breng vervolgens de updates aan op het juiste moment.<\/P>
Resource Contention and Expansion<\/H2>Soms worden best practices en strategieën voor prestaties toegepast, maar zijn lagere responstijden en hogere schaalbaarheid nog steeds vereist. Misschien is de huidige hardware waarop ArcGIS Server draait gewoon uitgeput, waarbij de verwerkingskracht of het geheugen de bottleneck vormen voor verbetering van de gebruikerservaring.<\/P>Voor dergelijke situaties moet u uitbreiding en/of upgrading van de hardware overwegen.<\/DIV>
Schaalbaarheid<\/SPAN>
Voor de ArcGIS Server en ArcGIS Web Adaptor lagen van de implementatie heeft u over het algemeen< \/STRONG >< \/EM >de volgende opties om schaalbaarheid< \/EM > te verbeteren met hardware: < \/SPAN >< \/DIV >Opschalen< \/STRONG >Meer resources toevoegen aan de bestaande machine (bijv. extra verwerkingskernen)< \/SPAN >Extra geheugen kan ook helpen bij opschalen door meer gelijktijdige ArcSOC-instanties mogelijk te maken< \/SPAN > < \/SPAN >< \/LI >< \/UL >< \/LI >Ideaal voor implementaties zoals: cloud, virtualisatie, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >Uitbreiden (scale out)< \/STRONG >Meer machines toevoegen met gelijke resourcecapaciteit< \/SPAN >< \/LI >Ideaal voor implementaties zoals: on-premise, cloud, virtualisatie, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >Prestaties< \/SPAN >Om prestaties< \/EM >met hardware te verbeteren, is er meestal maar één optie:< \/SPAN >Snellere verwerkingskernen verkrijgen< \/STRONG > Ideaal voor implementaties zoals: cloud, Kubernetes< \/SPAN >< \/LI >< \/UL >< \/LI >< \/UL >De pagingconfiguratie van het systeem kan ook invloed hebben op schaalbaarheid, zelfs wanneer er voldoende geheugenbronnen aan een systeem zijn toegevoegd. Hoewel dit een besturingssysteemsoftware-instelling is en geen hardware, kan het een cruciale rol spelen bij het draaien van veel gelijktijdige ArcSOC-instanties. Zorg ervoor dat dit correct is ingesteld om een werklast met veel instanties of instanties met een groot geheugenverbruik aan te kunnen.< \/FONT >Er kunnen situaties zijn waarin prestaties beperkt zijn en CPU-bound lijken (bijv. een bottleneck door beperkte verwerkingskracht). Nadere inspectie kan onthullen dat "de schuldige" één of meer trage queries zijn die vanaf het begin suboptimaal waren of een dure bewerking die te vaak werd aangeroepen (via periodieke administratieve taken). In zo'n geval kan het effectiever zijn om die "slechte" queries aan te pakken om prestaties en schaalbaarheid te verbeteren.< \/FONT >Opmerking: Deze uitbreidingsstrategieën zijn bedoeld om algemene verwerkings- en geheugengebonden beperkingen te overwinnen. Maar schijf- en netwerk(bronbreedte, latentie)bronnen kunnen ook bottlenecks vormen. Voor sommige omgevingen kunnen deze moeilijker uit te breiden zijn en aanvullende stappen vereisen voor upgrading.< \/STRONG >Een algemene benadering van opschalen< \/FONT >
Voor ArcGIS Server kan het gemakkelijker zijn eerst op te schalen (scale up), daarna uit te breiden (scale out). De reden hiervoor ligt in de Site-configuratie en directories die naar gedeelde opslag moeten worden gemigreerd als de architectuur wordt gewijzigd van een enkele machine naar een multi-machine implementatie.< \/DIV > < \/DIV > < \/DIV >Hoeveel moet u opschalen... twee servers, vijf servers? Zonder details over gemiddelde responstijden en het verwachte aantal gebruikers is het moeilijk om een beknopt antwoord te geven.< \/P >Een eenvoudige,algemene <\/STRONG >benadering zou zijn om gewoon dubbelen <\/U >van de huidige hoeveelheid (geheugen en/of fysieke verwerkingskernen) te proberen en het effect te observeren.<\/P > <\/Div > <\/Div > <\/Div > <\/Div > <\/Div > <\/Div > id="toc-hId-333806091">Observeerbaarheid "Quantifying ArcGIS" is een geweldige strategie... een persoonlijke favoriet. Het definieert welke resources werden opgevraagd en hoe snel de reacties waren om aan deze verzoeken te voldoen. Het is belangrijk voor het verkrijgen van inzicht in de algemene systeemprestaties. Als ook het gebruik van systeemresources kan worden vastgelegd, kan de analyse verder worden verbeterd.
Er zijn veel hulpprogramma's beschikbaar om uw systeem periodiek te onderzoeken. Sommige tools kunnen de toegangslogboeken lezen en richten zich voornamelijk op de statistische prestatie van verzoeken die door gebruikers zijn gedaan. Andere kunnen de statistiekpagina van Server poll-en en het CPU-gebruik (van ArcGIS Server of de database) voor die tijdsduur vastleggen. Welke aanpak is het beste? Als observeerbaarheid momenteel niet plaatsvindt, dan is waarschijnlijk elk van hen een goede aanvulling. Ze helpen allemaal om enig inzicht te bieden in de prestaties en gezondheid van de implementatie.
Zodra een analyse is uitgevoerd voor een implementatie, kunnen er doorgaans rapporten worden gegenereerd die aangeven welke kaartservices mogelijk interessant zijn vanwege:
- De waargenomen reactietijden die langzamer zijn dan verwacht
- Het aantal verzoeken dat voor de resource is uitgegeven
- Zowel reactietijd als aantal verzoeken
Voor een ArcGIS Site met veel services helpt het weten welke statistisch traag zijn of de meeste resources verbruiken om afstemmingsinspanningen te richten. Met dergelijke rapporten heeft de GIS-beheerder gegevens omgezet in waardevolle informatie en is nu beter geïnformeerd bij het nemen van beslissingen om de gebruikerservaring te verbeteren. Dat gezegd hebbende, het onderzoeken van logboeken en statistieken is slechts één (belangrijk) onderdeel van de analyse.
Een uitdaging met gangbare observeerbaarheidstools
Veel tools voor systeemobserveerbaarheid en monitoring richten de analyse op verzoeken en reacties voor services. Dit is een goede aanpak en helpt beheerders zeker bij het kwantificeren van ArcGIS, maar het kan een beperking hebben. De beperking kan zich voordoen met de aanname dat een trage kaartservice "gerepareerd" kan worden door simpelweg meer verwerkingskernen toe te voegen. Meer kernen kunnen sommige aspecten van de situatie verbeteren, maar het wordt aanbevolen dat de service grondiger (of zelfs opnieuw) wordt onderzocht voordat er meer resources worden verkregen.
Dit verwijst terug naar het gedeelte "Focus the Map", bijvoorbeeld:
- Zorg ervoor dat de gegevens voor de service niet op te kleine schalen worden weergegeven
- Vermijd suboptimale queries
Gedetailleerde query-analyse kan helpen om het voorkomen van deze gedragingen aan te tonen die mogelijk worden verborgen bij algemene servicerapportage. Echter, terwijl de uitsplitsing van serviceverzoekparameters en de onderliggende queries de analyse kan verbeteren, kan dit complexiteit toevoegen aan de rapportage zelf (bijv. meer tijd om uit te voeren, meer weergaven om naar te kijken, het begrijpen van de weergaven). Bovendien voeren niet alle observeerbaarheidstools dit type inspectie uit.
Sommige recente inspanningen die aan populariteit winnen proberen dit probleem aan te pakken. Ze zijn gebaseerd op een bottom-up benadering van analyse waarbij het startpunt ligt bij de onderliggende databasequeries zelf via een mechanisme dat bekend staat als "query datastore". Query datastore-analyse is krachtig en beïnvloedt de databaseprestaties niet zoals een trace dat kan, maar vereist wel enige kennis van de queries zelf en hun doel. Kijk in de toekomst uit naar dit type analysemogelijkheid om het meeste uit uw observeerbaarheidstools te halen.
Conclusie
Er is geen enkel item dat gemakkelijk kan worden aangepast om de prestaties en schaalbaarheid van een ArcGIS Enterprise Site te verbeteren. Dit artikel somt echter enkele veelvoorkomende strategieën op die samen kunnen worden toegepast om dit te verbeteren. Het is ook belangrijk te begrijpen dat dit items zijn die periodiek moeten worden herzien en opgevolgd. Gebruikersgewoonten veranderen in de loop der tijd, net als de populariteit van een webapplicatie of service. Resources die aan een bepaalde service waren toegewezen, kunnen opnieuw worden geëvalueerd of verminderd om ruimte te maken voor het volgende uitgelichte item in uw Site.
ArcGIS-prestatieanalyse kan leuk zijn, maar het is ook een voortdurende inspanning om de beste gebruikerservaring te behouden.
Auteursvermelding
Bron: Bestand:Grayson_running_the_4x100.jpg
Beschrijving: Engels: Grayson rent het eerste traject van de 4x100 op de Tigered-uitnodiging 2010
Auteur: Graysonbay
Aangemaakt: 02:02, 29 november 2010
Licentie: Dit bestand is gelicenseerd onder de Creative Commons Attribution 3.0 Unported licentie
Bron: Bestand:Kurvimeter_1_fcm.jpg
Auteur: Frank C. Müller, Baden-Baden
Licentie: Dit bestand is gelicenseerd onder de Creative Commons Attribution-Share Alike 4.0 International licentie.
Bron: Bestand:My_Opera_Server.jpg
Beschrijving: Een server gebruikt voor My Home
Auteur: William Viker, william.viker@gmail.com (c) 2006
Licentie: De auteursrechthebbende van dit bestand staat iedereen toe het voor elk doel te gebruiken, mits de auteursrechthebbende correct wordt vermeld. Hernieuwing, afgeleid werk, commercieel gebruik en alle andere gebruik zijn toegestaan.
Bron: Bestand:Samsung-1GB-DDR2-Laptop-RAM.jpg
Beschrijving: Een stick van 1 gigabyte DDR2 667 MHz (PC2-5300) laptop RAM, gemaakt door Samsung en gehaald uit een MacBook-laptop uit 2007.
Auteur: Evan-Amos
Aangemaakt: 1 augustus 2018
Licentie: Public Domain
