Doporučené strategie pro zátěžové testování nasazení ArcGIS Serveru
- Začněte s testovacím plánem
Většina testovacích softwarů může po dokončení testu vytvořit nějaký typ zprávy. Tato zpráva by měla odpovědět na otázky, které si kladl testovací plán.
Například:
a) Mohl by ArcGIS service využít veškerý CPU (např. CPU-bound)?
b) Mohl by ArcGIS service dodat specifický průtok (např. určitý počet transakcí/sekundu)?
c) Dodal průtok průměrnou dobu odezvy, která splnila naše požadavky na výkon?
Definování účelu testu pomáhá udržet testovací úsilí zaměřené na cíl.
- Testy by měly být prováděny na aplikaci bez známých závažných chyb nebo defektů
Zátěžové testování by nemělo být používáno k funkčnímu testování nasazení nebo aplikace.
Aplikace by měla projít kontrolou kvality (QA) před provedením zátěžových testů.
Navíc, pokud aplikace obsahuje závažné chyby, takové nedostatky by mohly mít měřitelný dopad na výkon a škálovatelnost nabízených služeb. To by pravděpodobně negovalo výsledky testu a potenciálně zbytečně plýtvalo časem, penězi a zdroji.
- Interagujte se svou aplikací (a ArcGIS services) před jejich zátěžovým testováním
Pokud jste jediným uživatelem ve svém systému a ArcGIS services reagují velmi pomalu, není potřeba provádět test pod zátěží. Dalším krokem by mělo být ladění a optimalizace ArcGIS services pro výkon.
- Koordinujte provádění testů
Často je zátěžový test prováděn v QA/Staging nebo Test prostředí, ale občas může být proveden i v produkci.
Ať už je prostředí jakékoli, je důležité si uvědomit, že často jsou služby a zdroje využívány i jinými uživateli (a nejen týmem pro zátěžové testování).
Pro lepší přehlednost a vyhnutí se neočekávaným situacím se důrazně doporučuje koordinovat provádění jakýchkoli zátěžových testů s příslušným personálem.
Tím lze zajistit lepší zkušenost skutečných uživatelů a vyhnout se nežádoucím rušením v zátěžovém testu (způsobeným akcemi skutečných uživatelů).
- Ověřte, že Testovací prostředí odpovídá očekávání
Někdy může být Testovací prostředí omezeno z různých důvodů. Postupem času se pak Test a Produkce stávají výrazně odlišnými prostředími. V takovém případě mají výsledky získané z Testu malý význam vzhledem k tomu, jak bude Produkce fungovat nebo škálovat.
Například:
a) Pokud se očekává, že Produkce bude nasazena s Vysoce dostupnou architekturou, měl by tomu odpovídat i Test
b) Pokud se očekává, že Produkce bude využívat enterprise geodatabase obsahující 500GB vektorových dat, měl by tomu odpovídat i Test
c) Pokud Produkce používá ArcGIS Servers se 32 jádry a maximální počet instancí služby je nastaven na 32, měl by tomu odpovídat i Test
Udržování Testovacího a Produkčního prostředí synchronizovaných může pomoci poskytnout nejlepší hodnotu (a očekávání) výsledků. V případech, kdy vědomě nesouhlasí, poznamenejte si to před zahájením testování a ve všech závěrech vyplývajících z Testovacího prostředí.
- Začněte zátěžový test krokem 1
Použití kroku 1 jako počáteční zátěže může pomoci vaší následné analýze po testu.
Krok 1 (nebo jeden současný testovací vlákno) představuje nejlepší scénář pro váš test. Toto je vaše základní hodnota a dobré měřítko pro pochopení toho, jak dobře nebo špatně ArcGIS service škáloval s rostoucím tlakem (např. když byla přidána další testovací vlákna).
- Sbírejte využití hardwaru ze všech strojů zapojených do testu
Většina testovacích rámců obvykle poskytuje možnost sbírat využití hardwaru ze serverů i samotného klienta pro testování. To může být cenné pro pochopení spotřeby zdrojů a identifikaci úzkých míst (např. zdroje na klientovi mohou také představovat omezující faktor).
Nicméně i přes tuto funkci v testovacím softwaru není vždy možné sbírat využití hardwaru kvůli oprávněním nebo síťovému přístupu (např. připojení přes firewally/routery).
Zatímco získání těchto informací přímo přes testovací rámec je jistě pohodlné, existují i jiné způsoby, jak tento úkol splnit. Použití bezplatných nástrojů jako PerfMon ve Windows nebo dtstat v Linuxu k zachycení těchto dat je další krok, ale stojí za to. Po dokončení testu lze stále provést analýzu na ručně vytvořených datech grafu z využití hardwaru.
- Nejprve otestujte jednotlivé ArcGIS services
Pokud konkrétní webová aplikace používá více než jednu ArcGIS service, otestujte a dolaďte každou zvlášť.
Tento přístup usnadňuje identifikaci služeb, které mohou mít úzká místa nebo omezení bránící jim využít dostupný hardware.
Pokud ArcGIS service nemůže využít veškerý dostupný CPU hardware ArcGIS Serveru, tester/analytik by měl upozornit příslušnou osobu na existující příležitost k ladění nasazení.
Také se vyhněte zahájení testovacího úsilí s celým pracovním tokem aplikace, protože může být obtížné odhalit potenciální úzká místa při současném testování mnoha ArcGIS services.
- Testujte co nejfyzicky blíže nasazení
Snažte se netestovat „simulací“ Internetu. Testování co nejfyzicky blíže nasazení může pomoci poskytnout nejlepší pochopení toho, co může serverový hardware dodat.
Úmyslné zavádění síťové latence nebo špatné šířky pásma přidá do testu šum a ztíží rozpoznání plného potenciálu ArcGIS services a serverů, na kterých běží.
- Krok a délka trvání testu
Testy nemusí běžet osm hodin, aby poskytly užitečné informace o dané ArcGIS service. Nicméně se také doporučuje vyhnout příliš krátkému zátěžovému testu. Jde o výběr délky doby testu (a délky každého kroku), která poskytne správné množství informací. Jinými slovy jde o zaznamenání dostatečného počtu vzorků požadavků pro získání „dobrého“ průměru.
Délka doby použitá obvykle souvisí s vaší dobou odezvy – rychlá doba odezvy může dodat mnoho požadavků během pětiminutového kroku zatížení. Pomalá doba odezvy může potřebovat patnáctiminutový krok zatížení k zaznamenání stejného počtu hodnot.
Jako tester nemusíte vždy odhadnout správně krok a délku trvání při prvním pokusu a možná budete muset upravit a opakovat test.
- Mějte na paměti úroveň protokolování ArcGIS Server Log Level
I když protokoly ArcGIS Server mohou poskytnout mnoho informací k analýze, je důležité pochopit, že vyšší úrovně protokolování VERBOSE a DEBUG mohou zpomalit výkon velmi vytíženého webu a nejsou doporučeným nastavením pro produkční prostředí. Hodnota WARNING (výchozí) poskytuje nejlepší možný výkon služby tím, že zaznamenává pouze varování a chyby.
Nastavení FINE je však dobrým kompromisem mezi užitečnými analytickými informacemi (jako jsou uplynulé časy u dynamických požadavků) a rychlostí.
- Tradiční ArcGIS services lze ladit v rámci (ArcGIS) Server
Než začnete zátěžově testovat tradiční (např. dedikovanou) ArcGIS service za účelem jejího ladění nebo pochopení jejího výkonu, zkuste nastavit hodnotu maximálního počtu instancí ArcSOC na počet CPU jader dostupných na ArcGIS serveru.
Po restartování služby toto nastavení umožní více současným požadavkům využít dostupný hardware a ukázat jej v tom nejlepším světle (za předpokladu, že služba je CPU-bound).
style="padding-left : 30px;">Zvýšení maximální hodnoty instance ArcSOC také umožní službě využívat více CPU, ale zároveň i více paměti. Ujistěte se, že na stroji ArcGIS Server je k dispozici dostatek paměti pro tuto úpravu. Pokud služba není silně zatížena, nadbytečné instance se stanou neaktivními (výchozí hodnota je 1800 sekund) a budou ukončeny, aby uvolnily paměť serveru.<\/P>
Podobně je dobrá strategie zvýšit minimální počet instancí služby (tak, aby odpovídal maximu) pro dosažení předvídatelného výkonu. Toto se doporučuje pro nejoblíbenější služby, ale mějte na paměti, že taková konfigurace bude vždy spotřebovávat paměť (pro danou službu), protože žádné instance nebudou ukončeny po uplynutí doby nečinnosti.<\/P>
Sdílené služby mají také nastavení instancí, které lze upravit. Nicméně pokud je sdílená služba natolik populární, že je testována zátěží, měla by být upravena tak, aby běžela jako tradiční dedikovaná služba.<\/P>
- Ne všechny ArcGIS služby jsou vázány na CPU<\/STRONG><\/LI><\/UL>Pokud je ArcGIS služba vázána na CPU, znamená to, že množství průtoku dat (nebo kapacita, kterou může podporovat) je omezeno pouze počtem CPU na stroji/strojích ArcGIS Serveru. V mnoha ohledech to může být výhodné.<\/P>Nicméně to není vždy pravda. Někdy mohou být úzká místa v jiném hardwaru, například v síti. Občas můžete narazit na úzké místo v softwarové komponentě, což může být záměrné nebo neúmyslné.<\/P>Proto je sběr hardwarových metrik během testu velmi důležitý. Sledování využití CPU, paměti, sítě a disku může poskytnout testerovi/analytikovi zásadní informace pro pochopení, zda něco omezuje škálovatelnost služby ArcGIS Server a zda jde o hardware serveru nebo testovacího klienta.<\/P>Jde o průtok (ne uživatele)<\/STRONG><\/LI><\/UL>Průtok se měří, uživatelé se počítají… jsou to dva odlišné artefakty z testu.<\/P>V testu je průtok obvykle definován jako transakce za sekundu (nebo operace za sekundu), a toto je hodnota, kterou by měl měřit testovací klientský software. Na druhou stranu definice „uživatele“ může být různá, ale obvykle se vypočítává z průtoku.<\/P>Protože průtok je přímo pozorován z výsledků zátěžového testu, je to jedna z nejlepších metrik pro určení škálovatelnosti nasazení.<\/P>Souvisejícím poznámkou je, že testovací vlákno (např. položka, která se zvyšuje s přidáváním většího zatížení do zátěžového testu) není totéž co uživatel. Počet využitých testovacích vláken a jejich délka jsou obvykle konfigurovány v definici krokového zatížení testu.<\/P>Ověřte, že test byl úspěšný<\/STRONG><\/LI><\/UL>Dokončení testu nemusí nutně znamenat, že byl „dobrý“ a schopný úspěšně odpovědět na otázky v testovacím plánu. Je důležité ověřit a potvrdit, že test posílal správné požadavky tam, kde měl, a dostával očekávané odpovědi.<\/P>Rychlá manuální kontrola kvality (QC) složení požadavků v testu může pomoci s prvním bodem.<\/P>Sledování průměrné délky obsahu (na odpověď) může pomoci s druhým bodem.<\/P>Většina testovacích softwarů poskytuje možnost zachytit průměrnou délku obsahu (nebo něco podobného). Obecné pravidlo je, že průměrná hodnota této metriky by měla během testu zůstat relativně konstantní. Pokud výrazně vzroste nebo klesne, doporučuje se další vyšetřování, protože očekávaná odpověď na požadavky nemusí přicházet (např. chyby místo obrázku nebo json obsahu) nebo pokud je odpověď platná ale velmi proměnlivá, může být potřeba jiný návrh testu.<\/P>Dále je důležité zjistit, zda byly samotné požadavky úspěšné (např. HTTP 200). Některý testovací software může umožnit analytikovi konfigurovat validační kontroly odpovědí přímo v rámci testu. Nicméně profilování metriky průměrné délky obsahu obvykle poskytuje přesnější pohled na očekávanou odpověď ze serveru.<\/P>Výsledky testů nejsou zárukou podpory X počtu uživatelů<\/STRONG><\/LI><\/UL>Výsledky testů pouze potvrzují otestovaný pracovní postup. Tento otestovaný pracovní postup ukáže průtok pro specifický typ požadavku s odpovídajícím časem odezvy. Neslibuje ani nezaručuje, že nasazení podpoří X počet uživatelů.<\/P>Pamatujte, že definice uživatele může být různá a může znamenat různé věci pro různá nasazení.<\/P>Vyhněte se testování sdílených zdrojů jako ArcGIS Online nebo Google Maps<\/STRONG><\/LI><\/UL>Bezplatné a veřejné služby od ArcGIS Online nebo Google Maps jsou určeny pro „komunitu“. Takové zdroje jsou poměrně robustní a škálovatelné, ale nelze je ladit z hlediska výkonu pro každého uživatele.<\/P>Protože nejsou přímo součástí on-premise nasazení, měly by být považovány za „externí“ zdroj. V důsledku toho by měly být požadavky na ně odstraněny ze zátěžového testu, protože test by se měl zaměřit výhradně na schopnosti vlastního hardwaru.<\/P>Opakovatelné výsledky testů<\/STRONG><\/LI><\/UL>Pokud výsledky zátěžového testu proti službě ArcGIS Server ukazují podobné trendové linie napříč jednotlivými běhy testů (např. stejný průtok je dosažen přibližně ve stejném bodě během testu), zdroj je obecně považován za „stabilní“. Schopnost opakovat výsledky testu je dobrá vlastnost.<\/P>Když výsledky nejsou okamžitě opakovatelné, tester/analytik musí jít hlouběji a pokusit se pochopit nekonzistentní chování. Může to být způsobeno tím, že hardware byl používán k obsluze jiných požadavků než těch z testu (např. jiný uživatel na systému). Nebo pokud bylo nasazení na sdílené infrastruktuře (např. virtualizace), základní hardware byl využíván k jinému účelu (jiné virtuální stroje prováděly náročné úkoly). V takových případech může provádění zátěžových testů mimo špičku přinést reprodukovatelnější výsledky ukazující potenciál stability služby.<\/P>Návrh testů/pracovních postupů by měl být realistický a založený na tom, co by uživatel očekával<\/STRONG><\/LI><\/UL>Vyhněte se teoriím a projekcím; zaměřte se jen na to, jak by uživatel měl aplikaci používat... očekávaný pracovní postup.
Zátěžové testování může být snadné provést, ale také snadno rozšířit rozsah testování o nepotřebné nebo nepravděpodobné scénáře.<\/P>Pochopte hodnotu<\/STRONG><\/LI><\/UL>Často je cesta k dobrému a užitečnému testu stejně důležitá jako samotný test. Jako analytik vám to pomůže:<\/P>a) Ověřit postupy testování<\/P>b) Mít největší schopnost vysvětlit výsledky, což zase činí váš test cenným<\/P> 1) Někteří jednotlivci nebudou chtít jen výsledky ale i analýzu a závěry<\/P> 2) Buďte připraveni tyto závěry podložit daty<\/P>Udržujte to jednoduché<\/STRONG><\/LI><\/UL>Někdy jsou nejvíce informativní testovací snahy jednoduché a nepříliš složité.<\/P>
