Výkon: Výzvy a strategie
ArcGIS Enterprise poskytuje robustní a škálovatelnou platformu pro poskytování GIS zdrojů uživatelům prostřednictvím služeb a webových aplikací. Někdy však může dojít k pomalému výkonu z publikovaných koncových bodů zdrojů.
Jelikož je ArcGIS velmi všestranný, existují různé způsoby, konfigurace a možnosti, jak tyto zdroje zpřístupnit k využití.
Získání dobrého výkonu není vždy tak jednoduché a přímočaré jako jen přepnutí nastavení "fast = true".
Co může být užitečnou funkcí pro některé administrátory, může být konfigurace, která i když je užitečná, může narušovat výkon pro jiné.
Ve skutečném světě je výkon často funkcí několika položek a konfiguračních nastavení. Mít strategie pro pochopení a překonání těch nejběžnějších může pomoci nasazení na cestě k dosažení rychlejšího výkonu.
Co je výkon?
Výkon je popis toho, jak rychle (nebo pomalu) server nebo služba funguje pro konkrétní funkci zájmu. Jak dlouho trvá ArcGIS Server service dokončit operaci jako query, applyEdit nebo export a pak odeslat odpověď zpět klientovi, který ji požadoval, by byl příkladem výkonu.
Tento časový úsek se měří v sekundách nebo milisekundách a běžně se označuje jako doba odezvy.
Ačkoli se nazývá "doba odezvy", existuje několik důležitých kroků, které tvoří celkový čas, který klient jako webový prohlížeč nebo ArcGIS Pro stráví čekáním na požadovaný serverový zdroj:
- DNS vyhledání názvu serveru
- SSL handshake mezi klientem a serverem
- TCP/IP spojení mezi klientem a serverem
- Odeslání požadavku na server
- Zpracování požadavku serverem
- Přijetí odpovědi ze serveru
- Pro velké odpovědi lze místo toho použít Time-to-first-byte (TTFB) k měření doby odezvy
Obvykle většina času je strávena v bodě 4.1. Zde server pracuje na odpovědi.
Tento článek Komunity prozkoumá oblasti, které mohou ovlivnit tuto část doby odezvy.
Proč je výkon důležitý?
Jednoduše řečeno: čím rychlejší výkon, tím nižší doba odezvy.
Čím nižší doba odezvy, tím více požadavků může server současně podporovat.
Tato vyšší souběžnost požadavků se překládá do větší škálovatelnosti, což nakonec znamená podporu více uživatelů.
Výkon se měří jako jednotka času potřebná k dokončení jedné operace najednou (např. 0,238 sekundy k provedení dotazu na prvek).
Škálovatelnost je na druhé straně často měřena jako transakce nebo operace za čas (např. požadavky/sekundu nebo operace/hodinu).
Když mluvíme o získání lepšího, rychlejšího nebo "více" výkonu, znamená to dosažení nižších dob odezvy. Na druhou stranu lepší škálovatelnost znamená dosažení vyšší propustnosti (např. více operací/hodinu).
Poznámka: Samozřejmě pro dosažení lepšího výkonu nebo propustnosti musí být operace zájmu správně vykonány a odpovědět s očekávaným obsahem (např. mapový obrázek, json nebo pbf data). Chybové zprávy například mohou být rychlou, jednoduchou odpovědí, jejíž doručení může dosahovat vysoké propustnosti. Jako testeři a analytici však nemáme zájem o tento typ propustnosti... zajímá nás propustnost úspěšných požadavků.
Co je přijatelný výkon?
Záleží.
Kritéria nebo požadavky pro klasifikaci položky jako rychlé (nebo pomalé) výkonnosti se mohou výrazně lišit podle organizace, publikovaných služeb a očekávaných operací, které budou uživatelé volat.
Není neobvyklé mít různé cíle doby odezvy pro funkce ArcGIS Server nebo pracovní postupy uživatelských aplikací (několik požadavků seskupených dohromady představujících jednu operaci).
Jakýkoli počet sekund je v pořádku jako požadavek, ale mějte na paměti, že může být potřeba více hardwaru i rozsáhlejší ladění a strategie (tento článek) k dosažení ambiciózních cílů.
Jak se měří výkon?
Doba odezvy je klíčovou metrikou pro určení, zda výkon splňuje nebo zůstává v rámci cílového požadavku či pod ním.
Běžné strategie měření jsou:
- Interakce jednoho uživatele
- Přes webový prohlížeč nebo ArcGIS Pro
- Toto je nejjednodušší místo pro začátek
- Pokud zatím není žádné porozumění výkonu, začněte zde
- Statistická analýza velkého množství dob odezvy
- Pomocí nástrojů pro analýzu logů, stránky Statistiky v ArcGIS Server Manager nebo jiných nástrojů pro observabilitu
- Tyto přístupy mají výhodu analýzy reálných požadavků, které uživatelé již proti nasazení provedli
- Toto je podrobněji diskutováno později v článku
- Zátěžové testování
- Může poskytnout pochopení výkonu a škálovatelnosti
- Nastavení zabere více času
- K dispozici jsou online zdroje pro začátečníky
Při analýze logů nebo provádění testů je běžnou strategií využití statistik pro rozdělení velkého množství dob odezvy. Průměrná hodnota a 90. (nebo 95.) percentil, minimum a maximum pomáhají poskytnout pochopení výkonu, který uživatel mohl zažívat.
Zachycení dob odezvy -- Webový prohlížeč
Způsob zachycení dob odezvy prostřednictvím interakce jednoho uživatele je zajímavé téma k diskusi.
Nejjednodušším způsobem zachycení dob odezvy REST požadavků z webové aplikace je pomocí funkce "vývojářské nástroje" v prohlížeči. Všechny hlavní prohlížeče nabízejí nějaký pohled na požadavky, odpovědi a časy odesílání a přijímání. Tato doba může dát představu o tom, jak rychle byla provedena žádost nebo operace (potenciálně více požadavků). Poté lze rozhodnout, zda je to přijatelné nebo zda to potřebuje zlepšit.
Zachycení dob odezvy -- ArcGIS Pro
Ačkoli ArcGIS Pro také komunikuje s ArcGIS Enterprise přes REST, nemá vestavěný ekvivalent vývojářských nástrojů. Pro zachycení dob odezvy budete potřebovat samostatný HTTP debugger. Existuje jich mnoho dostupných, populární volbou je Fiddler.
S Fiddlerem nainstalovaným na stejném počítači jako ArcGIS Pro lze nakonfigurovat zachytávání provozu. Parametry požadavků, obsah odpovědí a časy lze podobně zachytit a analyzovat.
Jsou cíle nutné pro zlepšení výkonu?
Nikoli vůbec ne. GIS administrátoři mohou vždy analyzovat, ladit a aplikovat osvědčené postupy v systému i bez oficiálních požadavků na výkon.
Nicméně se velmi doporučuje pochopit jaký výkon váš systém původně poskytuje (např. tyto hodnoty se obvykle označují jako základní čísla doby odezvy) před provedením úprav. Tímto způsobem můžete určit, zda aplikované změny mají pozitivní efekt.
Běžné výkonnostní výzvy a možné strategie
Typy Service Pool a instance
< DIV >< P >< SPAN > Jednou z nejčastějších oblastí , kde administrátoři ArcGIS čelí výkonnostním výzvám , je nastavení vhodného počtu instancí pro
dedikovanés služby . Ale nejprve si projdeme různé typy .
Existují 3 typy služeb , každý se svými vlastními silnými stránkami . </ P ></ DIV >< UL >< LI >< STRONG > Dedikované </ STRONG ></ LI >< LI >< STRONG > Hosted </ STRONG ></ LI >< LI >< STRONG > Sdílené </ STRONG ></ LI ></ UL >< DIV >< P > Jako GIS administrátor je důležité umět identifikovat typ instance pro služba.<\/P>Toto lze snadno zobrazit v ArcGIS Server Manager, v sekci Správa služeb:<\/DIV>
<\/DIV>
<\/span><\/P><\/DIV>Výběr vhodného typu<\/SPAN><\/H3>Volba dedikovaného typu služby je ideální, pokud chcete dosáhnout co nejlepšího výkonu a kontroly škálovatelnosti<\/U>. S tímto typem může administrátor:<\/P><\/DIV>Nastavit maximální počet instancí na počet jader CPU, aby plně využil dostupný výpočetní výkon stroje ArcGIS Server (pomocí maxima)<\/SPAN><\/LI>Šetřit paměť při nečinnosti (pomocí minima)<\/SPAN><\/LI>Upravit předvídatelný výkon nastavením minima a maxima na stejnou hodnotu<\/SPAN><\/LI><\/UL>Dedikované služby jsou ideální pro služby s vysokým počtem požadavků nebo tam, kde je výkon zásadní.<\/P>Hostované služby nevyužívají instance ArcSOC a automaticky škálují podle potřeby. Nicméně dostupné schopnosti ArcGIS pro ně (Hosted) jsou omezené, protože se primárně používají s dotazy na prvky.<\/P>Sdílené služby jsou skvělé pro přístup k položkám, které jsou požadovány méně často. Obvykle mají k dispozici více schopností ArcGIS, ale ne všechny funkce ArcGIS jsou dostupné (např. větvené verzování). Sdílený pool instancí je výchozí typ při publikování služby pomocí ArcGIS Pro<\/U>.<\/P>Poznámka: Je důležité zopakovat, že pokud je vybraný typ služby nastaven na dedikovaný, měl by být (minimální a maximální) počet instancí vyhodnocen, aby bylo zajištěno, že je optimální. Výchozí hodnota při publikování v ArcGIS Pro je použít maximálně 2 (instance). To může být příliš nízké a nedostatečné pro služby, kde jsou důležité výkon/škálovatelnost.<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>Zaměření mapy<\/H2>Optimalizace mapy není nová strategie, ale relativně snadná k dodržení pro dosažení lepšího výkonu z vašeho nasazení.
Když je mapa zaměřena na svůj hlavní účel a prezentaci, systém nemusí dělat zbytečnou práci. Pamatujte, že web je platforma pro více uživatelů. Zjednodušení zobrazení dynamických dat je klíčem k dobrému výkonu (a škálovatelnosti). Při potenciálně mnoha současných požadavcích musí být sdílený obsah co nejefektivnější.<\/P>
<\/span>Strategie mapy<\/SPAN><\/H3>Zvolte optimální výchozí rozsah<\/SPAN>Pokud mapa poskytuje data o Los Angeles, výchozí rozsah by neměl<\/EM> zobrazovat celé Kalifornie<\/LI>Pokud je potřeba mnoho různých měřítek mapy, použijte závislosti měřítka a generalizaci k omezení detailů na dobu, kdy je jich třeba nejvíce (např. největší měřítka)<\/LI><\/UL><\/LI>Odstraňte nepotřebné vrstvyZvažte odstranění vrstev dat, které jsou jen „pěkné mít“Alespoň je odznačte a nechte uživatele rozhodnout se pro jejich zapnutí<\/LI><\/UL><\/LI><\/UL><\/LI>Záměrně omezte, co uživatelé mohou se službou dělat<\/LI>Vyhněte se projekci za běhuPoužijte stejný souřadnicový systém pro datový rámec i data<\/LI><\/UL><\/LI>Definiční dotazyZajistěte existenci indexů, pokud se aplikuje logika porovnání na atributové sloupce <\/LI><\/UL><\/LI><\/UL>Poznámka: "Zaměření mapy" platí pro mapy, aplikace a služby<\/FONT><\/STRONG><\/DIV>Verze softwaru<\/H2>Konkrétní verze ArcGIS Enterprise (a jejích souvisejících řešení) může mít po svém počátečním vydání několik záplat. Tyto záplaty mohou nabídnout zlepšení výkonu stejně jako opravy funkcionality a bezpečnosti. <\/P>Doporučuje se pravidelně kontrolovat stránku Esri Patches and Updates<\/A> nebo spustit nástroj "Check for ArcGIS Enterprise Updates". Poté aplikujte aktualizace v odpovídajícím čase.<\/P>
Konkurence o zdroje a rozšíření<\/H2>Někdy jsou aplikovány nejlepší postupy a strategie pro výkon, ale stále jsou požadovány nižší doby odezvy a vyšší škálovatelnost. Možná současný hardware provozující ArcGIS Server je prostě vyčerpaný, kde výpočetní výkon nebo paměť se staly úzkým hrdlem pro zlepšení uživatelského zážitku.<\/P>Pro takové situace musíte zvážit rozšíření a/nebo upgrade hardwaru.<\/DIV>
Škálovatelnost<\/SPAN>
Pro vrstvy nasazení ArcGIS Server a ArcGIS Web Adaptor máte obecně<\/ id="toc-hId-333806091">Observabilita
„Kvantifikace ArcGIS“ je skvělá strategie... osobní favorit. Definuje, jaké zdroje byly požadovány a jak rychlé byly odpovědi na splnění těchto požadavků. Je důležitá pro získání přehledu o obecné výkonnosti systému. Pokud lze také zachytit využití systémových zdrojů, analýza může být dále vylepšena.
Existuje mnoho nástrojů dostupných pro periodické zkoumání vašeho systému. Některé nástroje mohou číst přístupové logy a primárně se zaměřovat na statistický výkon požadavků uživatelů. Jiné mohou dotazovat stránku statistik Serveru a zachytit využití CPU (ArcGIS Serveru nebo databáze) za dané časové období. Který přístup je nejlepší? Pokud momentálně neprobíhá observabilita, pak pravděpodobně kterýkoliv z nich bude dobrým doplňkem. Všechny pomáhají poskytnout určitý typ pohledu na výkon a stav nasazení.
Jakmile byla provedena analýza nasazení, obvykle lze generovat zprávy, které zdůrazňují, které mapové služby by mohly být zajímavé z důvodu:
- pozorovaných dob odezvy pomalejších než očekávané
- počtu požadavků na zdroj
- jak doby odezvy, tak počtu požadavků
Pro ArcGIS Site s mnoha službami pomáhá vědět, které jsou statisticky pomalé nebo spotřebovávají nejvíce zdrojů, zaměřit úsilí o ladění. Díky takovým zprávám správce GIS proměnil data ve cenné informace a je nyní lépe informován při rozhodování o zlepšení uživatelského zážitku. Nicméně zkoumání logů a statistik je jen jedním (důležitým) dílem analytického koláče.
Výzva u běžných nástrojů observability
Mnoho nástrojů pro systémovou observabilitu a monitorování se zaměřuje na analýzu požadavků a odpovědí služeb. To je dobrý přístup a rozhodně pomáhá správcům kvantifikovat ArcGIS, ale může mít omezení. Omezení může spočívat v předpokladu, že pomalou mapovou službu lze „opravit“ jednoduše přidáním výpočetních jader. Více jader může zlepšit některé aspekty situace, ale doporučuje se službu podrobněji prozkoumat (nebo dokonce znovu prozkoumat) před získáním dalších zdrojů.
Toto se vrací k sekci „Zaměřte mapu“, například:
- Zajistit, že data pro službu nejsou zobrazována v příliš malých měřítcích
- Vyhnout se suboptimálním dotazům
Podrobná analýza dotazů může pomoci ukázat výskyt těchto chování, která by mohla být maskována obecnými reporty služeb. Nicméně zatímco rozklad parametrů požadavků služby a základních dotazů může analýzu zlepšit, může také přidat složitost samotnému reportování (např. více času na provedení, více pohledů k prohlédnutí, pochopení těchto pohledů). Navíc ne všechny nástroje observability provádějí tento typ inspekce.
Některé nedávné snahy, které získávají na popularitě, se snaží tento problém řešit. Jsou založeny na bottom-up přístupu analýzy, kde výchozím bodem jsou samotné základní databázové dotazy prostřednictvím mechanismu známého jako „query datastore“. Analýza query datastore je silná a neovlivňuje výkon databáze jako trace, ale vyžaduje určité znalosti samotných dotazů a jejich účelu. V budoucnu očekávejte tuto schopnost analýzy, která vám pomůže získat maximum z vašich nástrojů observability.
Závěr
Neexistuje žádný jediný prvek, který by bylo snadné upravit pro zvýšení výkonu a škálovatelnosti ArcGIS Enterprise Site. Tento článek však uvádí některé běžné strategie, které lze aplikovat společně pro jeho zlepšení. Je také důležité pochopit, že tyto položky by měly být pravidelně revidovány a podle nich se má jednat. Uživatelské návyky se v průběhu času mění stejně jako popularita webové aplikace nebo služby. Zdroje přiřazené konkrétní službě lze přehodnotit nebo snížit, aby bylo místo pro další vybranou položku ve vašem Site.
Analýza výkonu ArcGIS může být zábavná, ale je to také kontinuální úsilí o udržení nejlepšího uživatelského zážitku.
Atribuce
Zdroj: File:Grayson_running_the_4x100.jpg
Popis: Anglicky: Grayson běží první úsek 4x100 na Tigered invite 2010
Autor: Graysonbay
Vytvořeno: 02:02, 29. listopadu 2010
Licence: Tento soubor je licencován pod Creative Commons Attribution 3.0 Unported licencí
Zdroj: File:Kurvimeter_1_fcm.jpg
Autor: Frank C. Müller, Baden-Baden
Licence: Tento soubor je licencován pod Creative Commons Attribution-Share Alike 4.0 International licencí.
Zdroj: File:My_Opera_Server.jpg
Popis: Server používaný pro My Home
Autor: William Viker, william.viker@gmail.com (c) 2006
Licence: Držitel autorských práv tohoto souboru umožňuje komukoliv jej použít pro jakýkoliv účel za předpokladu správného uvedení autora. Přerozdělování, odvozená díla, komerční použití a veškeré další použití jsou povoleny.
Zdroj: File:Samsung-1GB-DDR2-Laptop-RAM.jpg
Popis: Tyčinka 1 gigabajt DDR2 667 MHz (PC2-5300) laptop RAM vyrobená Samsungem a vytažená z MacBook laptopu z roku 2007.
Autor: Evan-Amos
Vytvořeno: 1. srpna 2018
Licence: Veřejná doména
