Dostupnost a využití ArcSOC
Optimalizace dostupnosti a využití instance ArcSOC pro vaši službu je dobrá strategie, která pomáhá uživatelům získat rychlé doby odezvy a nižší čekací doby na jejich dynamické požadavky na vašem webu. Může také prospět využití serverových zdrojů, jako je paměť, protože služba nespouští mnoho instancí, které nikdy nevyužije.
Ale optimalizace minimálního a maximálního počtu instancí pro vaše dedikované služby není jednorázová práce. Vzory používání vašich služeb se mohou v průběhu času měnit, takže úkol sběru těchto informací je něco, co budete chtít jako správce GIS pravidelně kontrolovat.
Než se ponoříme do toho, jak sledovat statistiky aktivity instancí ArcSOC, pojďme si shrnout některé klíčové detaily dvou typů služeb založených na ArcSOC v ArcGIS Serveru a jak zapadají do této diskuse:
Poznámka: Čekací doba je doba, kterou požadavek stráví ve „frontě“ na serveru, dokud není k dispozici instance ArcSOC, která může začít na něm pracovat.
Služby s dedikovaným bazénem instancí
Dedikované služby (např. nehostované a nesdílené služby) jsou základním zdrojem ArcGIS v nasazeních, protože mnoho aplikací závisí na schopnostech jako geoprocessing, úpravy Branch Version a pracovní postupy Utility Network (všechny vyžadují dedikované služby).
I když jsou tyto služby velmi všestranné a představují hlavní pilíř v ArcGIS díky funkcionalitě, kterou poskytují, jako správce GIS musíte pravidelně zkoumat, upravovat a konfigurovat počet instancí ArcSOC (minimální a maximální), abyste plně využili dostupné zdroje s růstem vašeho webu a uživatelů.
Pro více informací o instancích ArcSOC viz: Porozumění instancím služeb
Omezení služeb se sdíleným bazénem instancí
Sdílené instance služeb jsou skvělé! Jsou skutečnou revolucí pro pomoc správcům řídit poptávku po mnoha službách s omezenými zdroji. Nicméně jejich omezení a požadavky omezují, které schopnosti služeb lze s nimi používat. Například geoprocessing, úpravy Branch Version a Utility Network nejsou aktuálně podporovány přes sdílené služby (ani přes hostované služby). To ponechává dedikované služby jako jedinou volbu pro takovou funkcionalitu.
Konfigurovaná dostupnost instance ArcSOC vs poptávka po instanci
U služeb, které jsou velmi populární, kritické a/nebo mají požadavek běžet pod typem dedikované služby, je důležité pochopit optimální nastavení instancí z několika důvodů. Pokud je maximální počet aktivních instancí příliš vysoký, paměť je plýtvána (stejně jako náklady). Nadměrné přidělení instancí ArcSOC je důležitý ale specifický případ, protože jeho dopad by se neprojevil pouze v analýze dob odezvy.
Naopak příliš nízký maximální počet může ovlivnit výkon (ve formě vyšších dob odezvy a delších čekacích dob), protože uživatelé mohou často čekat na uvolnění již vytížené instance ArcSOC.
Samozřejmě nastavení minimálního a maximálního počtu instancí na různé hodnoty má také své kompromisy. U kritických služeb, kde je výkon zásadní, může čekání uživatele na spuštění nové instance zabrat čas a ovlivnit výkon. Proto pro předvídatelný výkon u nezbytných služeb se doporučuje nastavit minimální i maximální počet instancí na stejnou hodnotu.
Jak je uvedeno v Úvodu do instancí služeb:
Je tedy důležité pro správce ArcGIS Serveru sledovat počet instancí běžících na jejich webu a omezit běžící instance, pokud výkon omezuje využití paměti.
Konfigurace dostupnosti služby (prostřednictvím minimálních a maximálních hodnot instancí) a dopad těchto nastavení vzhledem k poptávce uživatelů po službě je klíčem k optimálnímu provozu webu. Existuje vzájemný vztah mezi konfigurací dostupnosti služby (minimálními a maximálními hodnotami instancí) a přímým dopadem na přicházející požadavky na dedikovanou službu. Ačkoli nalezení optimálního nastavení je průběžný úkol, existují nástroje a zdroje, které pomáhají správcům tuto výzvu zvládnout.
Zpráva o službách ArcGIS Serveru
Zpráva o službách Service Report v ArcGIS Serveru (představena ve verzi 10.1) je jedním z méně známých pokladů REST Admin API. Tento zdroj může pomoci sledovat web tím, že poskytuje konfigurovatelný souhrn všech služeb ve složce. Obecně jde o rychlý požadavek (v závislosti na počtu služeb ve složce).
Část statistiky instance služby ve vrácené odpovědi je nesmírně cenná, protože uvádí podrobnosti o instancích ArcSOC (minimální, maximální, vytížení) napříč celým nasazením (např. webem ArcGIS Server).
Pravidelným dotazováním tohoto koncového bodu lze získat aktuální přehled o konfiguraci instance služby vs poptávce... jak se to děje. S takovými informacemi lze činit lepší rozhodnutí o optimalizaci strojových a servisních zdrojů. To zase může pomoci zlepšit doby odezvy a snížit čekací doby.
Poznámka: V ArcGIS Serveru, statistiky instance služby a stránka Statistics v Manageru jsou vlastně odlišné zdroje i když poskytují podobné pohledy na stejná data. Statistiky služby poskytují surový přístup k hodnotám instance (celowebovým i podle stroje) stejně jako více detailů. Stránka Statistics je rozhraním pro vytváření zpráv z části těchto informací.
Automatizace sběru zprávy o službách pomocí Soccer
Jakýkoli skript, program nebo nástroj, který pravidelně sleduje koncový bod Zprávy o službách ve složce zájmu by byl dostačující. Nicméně pokud hledáte bezplatný existující nástroj, doporučuje se Soccer.
(Arc)SOC ScannER nebo Soccer je utilita pro skenování a čtení statistik služeb ve specifické složce ArcGIS Serveru. Parsuje sesbíraná data a zapisuje je do CSV souboru pro další analýzu po zachycení (např. tvorbu grafů v tabulkovém procesoru pro vizualizaci využití). Využívá REST Admin Service Report zdroj v ArcGIS Serveru k získání těchto informací. Původním cílem Soccer bylo zachytit výstup koncového bodu zprávy konkrétní složky v ArcGIS Serveru a uložit statistiky instance ArcSOC (např. Running, Busy, Maximum atd.) pro každou službu.
V současnosti je Soccer utilita pouze příkazového řádku. Je dostupná v přenosném .NET 6.0 runtime pro Windows (win-x64), Linux (linux-x64) a macOS (osx-x64).
Pro jednoduchost vyžaduje spuštění Soccer pouze 3 vstupy (další parametry lze předat pro rozšíření funkčnosti):
soccer.exe -s "[https://ArcGISServer/ServerWebAdaptor]" -f [FolderToScan] -t "[PreGeneratedArcGISToken]"
Například:
soccer.exe -s "https://gisserver.domain.com/server" -f "Gas" -t "APLeyWOcKZp9stZ_C01DQ.."
Poznámka: Předgenerovaný ArcGIS Server token lze získat z Portal. Obvykle je URL generateToken: https://gisserver.domain.com/portal/sharing/rest/generateToken a Webapp URL by pak bylo: https://gisserver.domain.com/server/admin. Nastavte hodnotu Expiration na něco vhodného pro očekávanou dobu monitorování.
Standardní výstup při spuštění z příkazového okna:
Připojeno k: "https://gisserver.domain.com/server " (Gas)
Stiskněte Ctrl-C dvakrát pro zastavení...
Spí 5 sekund...
Při běhu se soccer připojuje k Service Report koncovému bodu specifikované složky ArcGIS Serveru, sbírá data, zapisuje je do lokálního CSV souboru a poté spí. Po uplynutí doby spánku proces opakuje. Soccer bude sbírat data, dokud nebude proces ručně zastaven (Ctrl-C).
Poznámka: Pro sběr dat ze základní složky ArcGIS Serveru použijte buď: -f "/" nebo -f ""
Analýza CSV souboru
Ukázka obsahu zobrazená v jednoduchém textovém prohlížeči:
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,success
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,success
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,success
5/2/2023 1:12:50 AM,...
Poznámka: Podle návrhu budou sloupce jako IntervalSeconds a ResponseTimeMilliseconds zobrazovat duplicitní hodnoty pokud ve sledované složce existuje více služeb.
Sbíraná data jsou typické CSV soubory s několika důležitými poli užitečnými pro rychlou analýzu aktivity ArcSOC z našich služeb zájmu:
- IntervalSeconds
- ServiceName
- Running
- Busy
- Maximum
Otevřením CSV souboru v tabulkovém procesoru lze snadno filtrovat jiné služby ve stejné složce pomocí sloupce ServiceName. Hodnoty IntervalSeconds , Running , Busy , Maximum lze pak vykreslit pro vizualizaci (např. pomocí Scatter with Smooth Line grafu) a ukázat konfiguraci instance vůči příchozí poptávce. V tomto případě byla služba Gas_Utility_Network nastavena na min/max konfiguraci instance 32/32.
Následující „vyleštěný“ graf:
Poznámka: Maximum a Running představují maximální a minimální konfiguraci instancí služby ArcSOC. V tomto případě má Running stejné hodnoty a je vykreslen „za“ Maximum. Busy představuje počet instancí aktivních (kvůli požadavkům uživatelů) na všech strojích v Site.
Cílem ladění a optimalizace v tomto případě by bylo zabránit tomu aby hodnoty Busy neustále dosahovaly Maximum. Pokud by se to stalo znamenalo by to že nebylo dostatek ArcSOC dostupných pro službu k uspokojení poptávky uživatelů protože instance byly vždy vytíženy. Uživatelské požadavky by pak pravděpodobně zaznamenaly zvýšené doby odezvy a čekání v procesu. Pokud požadavky čekají příliš dlouho v systému vyprší časový limit (obvykle po 60 sekundách). Mnoho timeoutů požadavků služby by negativně ovlivnilo uživatelský zážitek.
Na základě pozorování během této monitorované doby hodnoty sloupce Busy nikdy nedosáhly maximálního počtu dostupných instancí… což z jednoho pohledu bylo dobré. Nicméně to také naznačovalo že existoval měřitelný počet běžících instancí zabírajících paměť ale nevyužívaných… což nebylo ideální.
Pro optimalizaci systémových zdrojů do budoucna mohla být konfigurace instancí této služby nastavena na nižší hodnotu blížící se (očekávanému) špičkovému využití (např. někde mezi 18 – 24).
- Použít 18 pro úsporu paměti s potenciálem setkat se s několika instancemi kde uživatelé čekají déle na splnění svých požadavků
- Použít 24 pro upřednostnění výkonu před využitím paměti
Závěrečné myšlenky
Mít „optimalizované“ nastavení služby pro minimální a maximální počet instancí nezaručuje že uživatelé nikdy nezažijí pomalý výkon. Potřeby a návyky uživatelů se v čase mění takže sledování těchto informací je něco co bude třeba dělat pravidelně.
V reálném světě existují situace kdy lze stále narazit na čekací doby služby i při dostatečném počtu instancí a dostatku systémových zdrojů. Není realistické úplně eliminovat čekací dobu služby ale je praktičtější ji snížit. Optimalizace instancí služby je něco co administrátoři mohou přímo ovlivnit a co má dopad na čekací doby.
Pochopení a pravidelné vyhodnocování konfigurace instancí ArcSOC (pro dedikované služby) a její vztah k poptávce uživatelů je klíčem k lepšímu plánování a správě Site GIS administrátory optimalizací výkonu a efektivním využíváním zdrojů.
