ArcSOC Beschikbaarheid en Gebruik
Het optimaliseren van de ArcSOC-instantiebeschikbaarheid en het gebruik voor uw service is een goede strategie om gebruikers te helpen snelle reactietijden en kortere wachttijden te verkrijgen bij hun dynamische verzoeken aan uw Site. Het kan ook het gebruik van serverbronnen zoals geheugen ten goede komen, omdat de service niet veel instanties draait die nooit gebruikt zullen worden.
Maar het optimaliseren van het minimum en maximum aantal instanties voor uw toegewijde services is geen eenmalige taak. Het gebruikspatroon van uw services kan in de loop van de tijd veranderen, dus het verzamelen van deze informatie is iets dat u als GIS-beheerder periodiek wilt herzien.
Voordat we ingaan op hoe ArcSOC-instantieactiviteitsstatistieken kunnen worden geobserveerd, laten we enkele belangrijke details bekijken van de twee op ArcSOC gebaseerde servicetypen in ArcGIS Server en hoe ze in deze discussie passen:
Opmerking: Wachttijd is de duur dat het verzoek in een "wachtrij" op de server doorbrengt totdat een ArcSOC-instantie beschikbaar is om eraan te beginnen werken.
Toegewijde Instantie Pool Services
Toegewijde services (bijv. niet-gehoste en niet-gedeelde services) zijn een vaste waarde binnen ArcGIS-implementaties, aangezien veel applicaties afhankelijk zijn van mogelijkheden zoals geoprocessing, Branch Version-bewerking en Utility Network-workflows (allemaal vereisen toegewijde services).
Hoewel dergelijke services zeer veelzijdig zijn en een belangrijke pijler vormen binnen ArcGIS vanwege de functionaliteit die ze bieden, moet u als GIS-beheerder periodiek het aantal ArcSOC-instanties (minimum en maximum) onderzoeken, aanpassen en configureren om optimaal gebruik te maken van uw beschikbare bronnen naarmate uw Site en gebruikers groeien.
Meer informatie over ArcSOC-instanties vindt u in: Begrijp service-instanties
Beperkingen van Gedeelde Instantie Pool Services
Gedeelde service-instanties zijn geweldig! Ze zijn echt een game changer voor het helpen van beheerders bij het beheren van de vraag naar veel services met beperkte middelen. Hun beperkingen en vereisten beperken echter welke service-mogelijkheden ermee kunnen worden gebruikt. Geoprocessing, Branch Version-bewerking en Utility Network worden bijvoorbeeld momenteel niet ondersteund via gedeelde services (of via gehoste services). Dit laat toegewijde services als enige keuze voor dergelijke functionaliteit.
Geconfigureerde ArcSOC Instantiebeschikbaarheid versus Instantie Vraag
Voor services die erg populair, kritisch en/of de eis hebben om onder het toegewijde servicetype te draaien, is het begrijpen van de optimale instantiebezetting belangrijk om verschillende redenen. Als het maximum aantal actieve instanties te hoog is, wordt geheugen verspild (evenals kosten). De overallocatie van ArcSOC-instanties is een belangrijke maar unieke situatie omdat de impact ervan niet zichtbaar zou zijn in alleen de analyse van reactietijden.
Aan de andere kant kan een te laag maximum de prestaties beïnvloeden (in de vorm van hogere reactietijden en langere wachttijden), omdat gebruikers mogelijk vaak moeten wachten tot een al bezette ArcSOC-instantie vrij komt.
Natuurlijk heeft het instellen van het minimum en maximum aantal instanties op verschillende waarden ook een afweging. Voor kritieke services waar prestaties essentieel zijn, kan het laten wachten van het verzoek van de gebruiker terwijl een instantie moet worden gestart tijdrovend zijn en de prestaties beïnvloeden. Daarom wordt aanbevolen om voor voorspelbare prestaties op essentiële services het minimum en maximum aantal instanties op dezelfde waarde in te stellen.
Zoals vermeld op Introductie tot service-instanties:
Het is daarom belangrijk voor ArcGIS Server beheerders om het aantal instanties dat hun site draait te monitoren, en om draaiende instanties te beperken wanneer prestaties worden belemmerd door geheugengebruik.
Het configureren van de beschikbaarheid van de service (via het minimum en maximum aantal instanties) en de impact van die instellingen vanuit de vraag van gebruikers naar de service is essentieel voor een optimaal functionerende Site. Er bestaat een wederzijdse relatie tussen het configureren van de beschikbaarheid van de service (via minimums en maximums) en het directe effect daarvan op binnenkomende verzoeken aan een toegewijde service. Hoewel het vinden van de optimale instelling een doorlopende taak is, zijn er enkele hulpmiddelen en bronnen om beheerders te helpen deze uitdaging aan te gaan.
ArcGIS Server Service Rapport
Het ArcGIS Server Service Rapport (geïntroduceerd in 10.1) is een van die minder bekende REST Admin API pareltjes. Deze bron kan helpen bij het monitoren van een Site door een configureerbare samenvatting te bieden van alle services in een map. Het is over het algemeen een snel reagerend verzoek (afhankelijk van het aantal services in de gevraagde map).
De instantiedienststatistieken-sectie van de geretourneerde respons is uiterst waardevol omdat deze details vermeldt over de ArcSOC-instanties (min, max, bezet) over de hele implementatie (bijv. de ArcGIS Server Site).
Door dit eindpunt periodiek te poll-en, kan men realtime inzicht krijgen in de configuratie van service-instanties versus de vraag... terwijl het gebeurt. Met dergelijke informatie kunnen betere beslissingen worden genomen over het optimaliseren van machine- en serviceresources. Dit kan op zijn beurt helpen bij het verbeteren van reactietijden en verlagen van wachttijden.
Opmerking: In ArcGIS Server, instantiedienststatistieken informatie en de Statistieken pagina in Manager zijn eigenlijk verschillende bronnen hoewel ze vergelijkbare weergaven bieden van dezelfde gegevens. De servicestatistieken bieden ruwe toegang tot de instantiegegevens (site-breed en per machine) evenals meer details. De Statistieken-pagina is een interface voor het maken van rapporten uit sommige daarvan.
Automatiseren van Service Rapport Verzameling met Soccer
Elk script, programma of hulpmiddel dat regelmatig het Service Rapport-eindpunt observeert voor de map waarin u geïnteresseerd bent, volstaat. Als u echter op zoek bent naar een gratis bestaand hulpmiddel dan wordt Soccer aanbevolen.
(Arc)SOC ScannER of Soccer is een hulpprogramma voor het scannen en lezen van statistieken van services in een specifieke ArcGIS Server-map. Het verwerkt de verzamelde gegevens en schrijft deze weg naar een CSV-bestand voor aanvullende analyse na vastlegging (bijv. grafieken maken in een spreadsheet om gebruik te visualiseren). Het maakt gebruik van REST Admin's Service Report-bron in ArcGIS Server om deze info te verzamelen. Het oorspronkelijke doel van soccer was om uitvoer vast te leggen vanaf het rapport-eindpunt van een specifieke map in ArcGIS Server en om ArcSOC-instantiestatistieken (bijv. Running, Busy, Maximum, enz.) voor elke service op te slaan.
Momenteel is soccer alleen beschikbaar als commandoregelhulpmiddel. Het wordt geleverd in de .NET 6.0 draagbare runtime voor Windows (win-x64), Linux (linux-x64) en macOS (osx-x64).
Voor eenvoud vereist soccer slechts 3 invoerparameters (andere parameters kunnen worden meegegeven om functionaliteit uit te breiden):
soccer.exe -s "[https://ArcGISServer/ServerWebAdaptor]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"
Bijvoorbeeld:
soccer.exe -s "https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."
Opmerking: Een vooraf gegenereerde ArcGIS Server-token kan worden verkregen via Portal. Meestal is de generateToken URL: https://gisserver.domain.com/portal/sharing/rest/generateToken en de Webapp URL zou dan zijn: https://gisserver.domain.com/server/admin. Stel de Expiration waarde in op iets dat passend is voor uw verwachte monitoringsduur.
Standaarduitvoer tijdens het uitvoeren vanuit een opdrachtvenster:
Verbonden met: "https://gisserver.domain.com/server " (Gas)
Druk tweemaal op Ctrl-C om te stoppen...
Slaapt 5 seconden...
Tijdens het uitvoeren maakt soccer verbinding met het Service Report-eindpunt van de opgegeven ArcGIS Server-map, verzamelt de gegevens, schrijft deze naar een lokaal CSV-bestand en slaapt vervolgens. Nadat de slaapduur is verstreken, herhaalt het proces zich. Soccer blijft verzamelen totdat het proces handmatig is gestopt (Ctrl-C).
Opmerking: Om te verzamelen op de root ArcGIS Server-map, gebruik ofwel: -f "/" of -f ""
Analyseren van het CSV-bestand
Voorbeeldinhoud zoals gezien vanuit een eenvoudige tekstviewer:
DateTime,Epoch,IntervalSeconds,Host,Folder,ServiceName,Type,Provider,Running,Busy,Maximum,Free,NotCreated,Initializing,Transactions,TotalBusyTime,ServicesCollected,ResponseTimeMilliseconds,ContentLength,ConfiguredState,RealTimeState,Message
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succes
5/2/2023 1:12:45 AM,1682989965310,5,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,121.6224,6065,STARTED,STARTED,succes
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Gas_Utility_Network,MapServer,ArcObjects11,32,0,32,32,0,0,0,0,2,117.901,6065,STARTED,STARTED,succes
5/2/2023 1:12:50 AM,1682989970469,10,gisserver.domain.com,Gas,Landbase_PostgreSQL,MapServer,ArcObjects11,32,0,32,32,0,0,0,0 ,2 ,117.901 ,6065 ,STARTED ,STARTED ,succes
5/2/2023 1:12:55 AM ,1682989975606 ,15 ,gisserver.domain.com ,Gas ,Gas_Utility_Network ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,109.6187 ,6065 ,STARTED ,STARTED ,succes
5/2/2023 1:12:55 AM ,1682989975606 ,15 ,gisserver.domain.com ,Gas ,Landbase_PostgreSQL ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,109.6187 ,6065 ,STARTED ,STARTED ,succes
5/2/2023 1:13:00 AM ,1682989980733 ,20 ,gisserver.domain.com ,Gas ,Gas_Utility_Network ,MapServer ,ArcObjects11 ,32 ,0 ,32 ,32 ,0 ,0 ,0 ,0 ,2 ,125.1686 ,6065 ,STARTED ,STARTED,succes
5/2/2023 1:13:00 AM ,1682989980733 ,20,gisserver.domain.com,G as,Gas_Utility_Network,M apServer,A rcObjects11,,32,, 032,,320,,00,,00,,02,,125.1686,,6065,, STARTED,, STARTED,, succes
5/2/2023 1:13:05 AM ,,1682989985874,,25,,gisserver.domain.com,,Gas,,Gas_Utility_Network,,MapServer,,ArcObjects11,,32,,00,,320,,320,,00,,00,,02,,116.3949,,6065,, STARTED,, STARTED,, succes
5/2/2023 1:13:05 AM ,,1682989985874,,25,,gisserver.domain.com,,Gas,,Landbase_PostgreSQL,,MapServer,,ArcObjects11,,32,,00,,320,,320,,00,,00,,02,,116.3949 ,,6065 ,,STARTED ,,STARTED ,,succes
Opmerking: Door ontwerp zullen kolommen zoals IntervalSeconds en ResponseTimeMilliseconds dubbele waarden tonen als er meer dan één service bestaat in de map die wordt geobserveerd.
De verzamelde gegevens zijn een typisch CSV-bestand maar er zijn enkele belangrijke velden die nuttig zijn voor het snel analyseren van de ArcSOC-activiteit van onze service(s) van belang:
- IntervalSeconds
- ServiceName
- Running
- Busy
- Maximum
Door het CSV-bestand te openen in een spreadsheet kunnen andere services die zich in dezelfde map bevinden gemakkelijk worden gefilterd via de kolom ServiceName. De waarden IntervalSeconds-, Running-, Busy-, Maximum kunnen dan worden uitgezet om te visualiseren (bijvoorbeeld via het Scatter with Smooth Line-diagram) en tonen de instantieconfiguratie versus binnenkomende vraag. In dit geval was de Gas_Utility_Network-service ingesteld op min/max instantieconfiguratie van 32/32.
De "verfijnde" grafiek hieronder:
Opmerking: Maximum en Running vertegenwoordigen respectievelijk de maximale en minimale ArcSOC-serviceconfiguratie-instanties. In dit geval heeft Running dezelfde waarden en wordt “achter” Maximum uitgezet. Busy vertegenwoordigt het aantal instanties dat actief was (vanwege verzoeken van gebruikers) over alle machines in de Site.
Het “doel” van afstemming en optimalisatie in dit geval zou zijn om te voorkomen dat de Busy-waarden constant het Maximum bereiken. Als dit zou gebeuren betekent dit dat er niet genoeg ArcSOCs beschikbaar waren voor de service om aan de gebruikersvraag te voldoen omdat de instanties altijd bezet waren. Gebruikersverzoeken zouden dan waarschijnlijk langere reactietijden en wachttijden ondervinden in het proces. Als verzoeken te lang wachten in het systeem verlopen ze (meestal na 60 seconden). Veel time-outs bij servicerequests zouden een negatieve invloed hebben op de gebruikerservaring.
Gebaseerd op de observaties van deze gemonitorde duur kwam de stijging en daling van de Busy-kolomwaarden niet in de buurt van het maximale aantal beschikbare instanties… wat vanuit één perspectief goed was. Echter duidde dit ook aan dat er een meetbaar aantal instanties draaide en geheugen gebruikte maar niet werd gebruikt… wat niet ideaal was.
Om systeembronnen voortaan te optimaliseren had de instantieconfiguratie van deze service kunnen worden ingesteld op een lagere waarde die dichter bij het (verwachte) piekgebruik ligt (bijvoorbeeld ergens tussen 18 – 24).
- Gebruik 18 om geheugen te besparen met het potentieel dat meerdere instanties gebruikers langer laten wachten op hun verzoeken
- Gebruik 24 om prestaties boven geheugengebruik te verkiezen
Slotgedachten
Het hebben van een “geoptimaliseerde” service-instelling voor het minimum en maximum aantal instanties garandeert niet dat gebruikers nooit trage prestaties zullen ervaren. Gebruikersbehoeften en -gewoonten veranderen in de loop der tijd dus het monitoren van deze informatie moet periodiek gebeuren.
In de praktijk zijn er omstandigheden waarbij servicetijden nog steeds kunnen voorkomen in een implementatie… zelfs met voldoende beschikbare instanties en voldoende systeembronnen. Het is niet realistisch om servicetijd volledig uit te sluiten maar praktischer om deze te verminderen. Het optimaliseren van service-instanties is iets waar beheerders direct controle over hebben en wat invloed heeft op wachttijden.
Begrip en periodieke evaluatie van de ArcSOC-instantieconfiguratie (voor toegewijde services) en de relatie tot gebruikersvraag is essentieel om GIS-beheerders beter te helpen hun Site te plannen en beheren door prestaties te optimaliseren en middelen efficiënt te gebruiken.
