Požadavek
Také známý jako sampler
HTTP request je "nejmenší" jednotka práce, kterou můžete definovat pro provedení testu. Obecně platí, že při testování ArcGIS Enterprise může jít o URL pro zdroj jako mapovou službu, feature službu nebo řešení trasy, ale může to být také volání statického objektu jako *.css nebo *.js soubor.
Protokol může být HTTP (prostý text) nebo HTTPS (zabezpečený) a metoda může být jedna z mnoha, i když GET POST a HEAD jsou obvykle nejběžnější.
Dynamický požadavek na mapovou službu by vypadal následovně:
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
Stejná URL jako Apache JMeter HTTP request:
Jak by vypadal statický požadavek:
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter také rozlišuje mezi request a sampler, i když oba definují akci k provedení. Sampler by byla exekuce procesu na úrovni operačního systému, která provádí nějaký typ akce, například spuštění geoprocessingového nástroje pro vytvoření file geodatabase nebo vytvoření nové SDE verze v enterprise geodatabázi. Každý test musí mít alespoň jeden request nebo sampler.
Dalším typem sampleru je web socket. I když je podobný HTTP request v tom, že volá přes "web" a může být zabezpečený, používá jiný protokol pro komunikaci s vzdáleným serverem a také jiné parametry pro specifikaci možností parametrů.
Transakce
Transakce je logická skupina jednoho nebo více http requestů. Požadavky mohou být dynamické a/nebo statické. Společně tyto požadavky obvykle tvoří jednu uživatelskou operaci, například:
- Nahrání webové aplikace
- Navigační akce jako posun nebo přiblížení
- Vyhledávací funkce
- Vytvoření nové SDE verze v rámci Enterprise GeoDatabase
Není technickou podmínkou používat transakce v testu, ale jejich použití může výrazně zlepšit analýzu, protože jednotlivé operace (např. transakce) lze pak izolovat a ukázat jejich příslušné výkonnostní chování během běhu testu. To může být velmi informativní.
Porozumění tomu, že pouze požadavky pro měřítko mapy 1:72 224 měly problémy s výkonem, je velmi užitečné z hlediska ladění, protože přesně víte, které oblasti mapového dokumentu nebo projektu je třeba
upravit... transakce vám mohou pomoci toho dosáhnout.
Apache JMeter Transakce obsahující tři požadavky z jedné operace:
Test
Také známý jako test plan nebo test project
Termín "test" je poměrně obecný a často se používá jak jako podstatné jméno (vytvořil jsem test pro volání zdroje), tak sloveso (budu testovat službu). Transakce a požadavky jsou obvykle definovány v testu. Test bude mít další možnosti konfigurace, jako například: jak dlouho bude test probíhat, kam půjdou výsledky, zda mají být sbírány metriky na vzdálených serverech.
Různé frameworky používají mírně odlišnou terminologii pro popis testu. V případě Apache JMeter se test nebo test project nazývá Test Plan a má příponu souboru *.jmx.
Krokové zatížení
Také známé jako load
Krokové zatížení je charakteristika definující, jak dlouho a kolik současných testovacích vláken se použije během testu prostřednictvím rovnoměrného, postupného zvyšování zátěže (např. podobně jako schodiště). Konfigurace testu pro krokové zatížení je užitečná pro pochopení toho, jak mapová služba funguje nebo škáluje, nebo jak se chovají nasazovací zdroje
při zvyšujícím se počtu požadavků. Definovaný tlak může také klesat (ke konci testu), ale nemusí.
Apache JMeter Thread Group (bzm - Concurrency) specifikující a vizualizující konkrétní krokové zatížení:
Konstantní zatížení
Konstantní zatížení také definuje, jak dlouho a kolik testovacích vláken se použije, ale obvykle je nastaveno na stálou rychlost po dlouhou dobu. Místo zaměření na výkon a škálovatelnost je tato konfigurace obvykle určena k pochopení odolnosti a stability.
Apache JMeter Thread Group (bzm - Concurrency) specifikující a vizualizující konkrétní konstantní zatížení:
Testovací vlákna
Také známá jako threads
Toto je mechanismus odpovědný za aplikaci zátěže tím, že bere definovanou práci k provedení v testu, jako jsou transakce a/nebo požadavky, a opakovaně je vykonává.
Testovací vlákna se obvykle chovají sériově, kde každé vlákno začíná čtením prvního request definovaného v testu, odešle ho na server a poté čeká na jeho odpověď. Další request v testu nebude odeslán, dokud nepřijde odpověď ze serveru nebo nevyprší časový limit. Jakmile je splněna jedna z těchto podmínek, pokračuje k dalšímu requestu. Většina testů je nakonfigurována tak, aby každé testovací vlákno tento proces opakovalo nepřetržitě po celou dobu běhu.
Různé technologie často označují testovací vlákna jako virtuální uživatele, ale to může být zavádějící. Testovací vlákna jsou jen prostředkem (tlakem) k cíli (dodanému průtoku).
Jinými slovy spuštění testu nakonfigurovaného s krokovým zatížením dosahujícím 100 testovacích vláken neznamená, že prostředí podporuje 100 současných virtuálních uživatelů. V tomto případě by počet uživatelů byl vypočítán podle průtoku testu; například transakcí za sekundu.
Apache JMeter Thread Group (bzm - Concurrency) definující krokové zatížení pomocí (testovacích) vláken:
Uživatelé
Také známí jako virtual users
Počet podporovaných uživatelů je jednou z nejčastějších otázek při určování zátěžového testu a obvykle má formu:
- Kolik uživatelů tato konkrétní služba nebo aplikace zvládne?
- Zvládne daná služba nebo aplikace alespoň X uživatelů?
Výpočet uživatelů je úzce spojen s think time stejně jako s měřenými artefakty testu jako průtok a doba odezvy.
Použití Little Law s těmito vstupy může poskytnout teoretický odhad počtu uživatelů, které prostředí může podporovat.<\/P>
Think Time<\/STRONG>
Také známý jako workflow pacing<\/STRONG><\/EM><\/H5>Think time je doba (definovaná v sekundách nebo milisekundách), která je přidána do testu, aby simulovala zpoždění lidského chování, ke kterému by docházelo při přirozené interakci osoby se službou mapy nebo webovou aplikací.
Zpoždění think time lze přidat k transakcím (např. operaci) nebo požadavkům, nebo dokonce k samotnému testu (což se pak nazývá workflow pacing). Způsob jejich přidání se může lišit v závislosti na použitém testovacím rámci.
V případě Apache JMeter je k dispozici několik různých časovačů, které lze přidat do testu pro simulaci různých typů zpoždění.<\/P>Klíčové ukazatele výkonnosti (KPIs)<\/STRONG><\/H5>KPIs jsou metriky testu, které pomáhají s analýzou zátěžového testu. Některé z nejpopulárnějších jsou spojeny s měřením doby odezvy a propustnosti testu. Nicméně také zahrnují položky, které počítají počet neúspěšných požadavků, průměrnou délku obsahu (na požadavek) nebo shromažďují informace o využití hardwaru (jako CPU, paměť, síť a disk).
Ačkoli schopnost zachytit využití hardwaru často vyžaduje další konfiguraci testu a oprávnění v prostředí, tyto informace jsou jedním z nejdůležitějších artefaktů zachycených ze zátěžového testu.<\/P>Poznámka: Zachycené využití hardwaru je jedním z nejdůležitějších artefaktů zachycených ze zátěžového testu.<\/FONT><\/STRONG><\/P>Doba odezvy<\/STRONG><\/H5>Doba odezvy je běžná metrika používaná k měření výkonu požadavku, transakce nebo testu. Jednoduše řečeno poskytuje pochopení toho, jak rychle operace probíhá.
Hodnota je obvykle prezentována v sekundách nebo milisekundách. Rychlejší výkon znamená nižší dobu odezvy, což se překládá do příznivější uživatelské zkušenosti. Doba odezvy může být zobrazena v průběhu trvání testu pro pochopení, jak se výkon měnil, nebo uvedena společně s propustností pro konkrétní bod v testu (např. kde propustnost dosáhla vrcholu).<\/P>Poznámka: Doby odezvy jsou jedním z nejdůležitějších artefaktů zachycených ze zátěžového testu.<\/STRONG><\/FONT><\/P>Ideálně bude výkon testované položky mít následující křivku, kde doby odezvy budou stoupat rychleji (kolem bodu maximální propustnosti). V následujícím příkladu byla průměrná doba odezvy požadavku při maximální propustnosti asi 0,4 sekundy.<\/P>
<\/span><\/P>Propustnost<\/STRONG>:<\/H5>Propustnost je běžná metrika používaná k měření škálovatelnosti mapové služby, webové aplikace nebo hardwarové infrastruktury. V podstatě poskytuje pochopení rychlosti, jakou lze provádět operace během určitého časového období.
Hodnota může být obvykle zachycena jako požadavky za sekundu, transakce za sekundu (např. operace za sekundu) nebo testy za sekundu, i když je často vyjádřena za dobu jedné hodiny (rychlost v sekundách vynásobená 3600).
Vyšší škálovatelnost znamená větší propustnost, což se překládá do podpory více uživatelů.
Některé analýzy testů se zaměřují na průměrnou propustnost všech transakcí během testu, zatímco jiné mohou zkoumat průměrnou propustnost pro každou jednotlivou operaci.<\/P>Poznámka: Propustnost je jedním z nejdůležitějších artefaktů zachycených ze zátěžového testu.<\/STRONG><\/FONT><\/P>Ideálně bude propustnost testované položky připomínat následující křivku, kde dosáhne vrcholu a poté se ustálí. <\/SPAN>Když propustnost dosáhne vrcholu a/nebo se ustálí, naznačuje to, že test narazil na nějaký druh úzkého místa. V následujícím příkladu byla průměrná propustnost požadavků při vrcholu asi 24 požadavků za sekundu (nebo 86 400 požadavků za hodinu).<\/P>
<\/span><\/P>Úzké místo<\/STRONG><\/H5>Úzké místo je stav nasazení, kdy jedna z jeho komponent nebo vrstev omezuje rychlost, jakou může reagovat na příchozí požadavky. Úzké místo může mít formu:<\/P>Příklady hardwaruVšechny CPU jádra ArcGIS Server jsou plně využityDostupná paměť je vyčerpánaI\O úložiště disku databázového serveru je plně využitoSíťová karta je nasycenakvůli odeslanému nebo přijatému provozu <\/LI><\/UL>Příklady softwaruDatabáze byla nakonfigurována tak, aby povolovala pouze 25 současných připojení i přes dostatek dostupných hardwarových zdrojůPropustnost při využívání mapové služby se ustálila, ale využití CPU ArcGIS Server nepřesahuje 25 %<\/LI>Úzké místo vždy existuje v nasazení a určení komponenty, která bude omezovat jako první, je součástí analýzy. Často bude potřeba zátěžový test k odhalení prvního úzkého místa, protože může být pozorováno pouze pod velkým tlakem. Zatímco zdroje serveru a nastavení jsou obvykle středem pozornosti analýzy úzkých míst, zdroje klienta testu (CPU, paměť, síť, disk a v některých případech i licence na testování) mohou být také faktorem. Dosáhnout úzkého místa není nutně problém; jen to ukazuje první slabinu nebo omezení v systému. Někdy je úzké místo považováno za „dobrou věc“, například při spuštění velkého procesu ukládání mezipaměti ArcGIS je žádoucí, aby CPU bylo prvním úzkým místem, protože vykonává práci na vytváření dlaždic mapy. Pokud CPU může dosáhnout pouze 50 % kvůli jinému úzkému místu (např. diskovému I\O), dokončení úlohy potrvá dvakrát déle ve srovnání s plným využitím CPU na 100 %.<\/P>Poznámka: Úzké místo vždy existuje v nasazení<\/STRONG><\/FONT><\/P>Druh testu<\/STRONG>
Také známý jako performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>Mnoho organizací často používá různé kategorie pro klasifikaci prováděného testování.<\/P>Performance test se obvykle používá k řešení problémů se službou nebo aplikací při pomalém chování nebo delších než očekávaných dobách odezvy. Nemusí zahrnovat krokové zatížení a může být pohodlně proveden jako jediný uživatel přímo interagující z webového prohlížeče s daným koncovým bodem.<\/P>Load test lze často použít k popisu krokového zatížení s cílem splnit konkrétní cíl propustnosti a doby odezvy. Například X transactions/sec<\/EM> s dobou odezvy pod Y sekundami<\/EM> a bez selhání. To může vést k vyčerpání jednoho ze serverových hardwarových zdrojů, ale to obvykle není cílem. Load test může být také označován jako scalability test.<\/P>Stress test je podobný test, ale často se zaměřuje na dosažení tlaku představujícího násobek cíle load testu. Jinými slovy pokud load test usiloval o dosažení X transactions/sec<\/EM>, stress test by mohl usilovat o dosažení X * 5 transactions/sec<\/EM> bez výrazného množství selhání.<\/P>Endurance test má zvláštnost snažit se porušit komponenty systému. Jeho aplikované zatížení může být násobkem stress testu s cílem být vystaven významným chybám a sledovat propustnost a dobu odezvy při jejich výskytu. Endurance test může být také označován jako durability test, kde aplikované zatížení je konstantní po velmi dlouhou dobu a sledují se vzory využití hardwaru a jeho obnovy.<\/P>Testovací plán<\/STRONG><\/H5>Obecně vzato je testovací plán dokumentem, tabulkou nebo seznam, který definuje konkrétní testy, které budou provedeny, stejně jako jejich příslušné cíle. Tyto cíle jsou důvodem a účelem každého testu. Analýza výsledků (ručně nebo z generovaných testovacích zpráv) by vám měla pomoci určit, zda byly cíle každého testu dosaženy.<\/P>Testing Framework <\/STRONG><\/H5>Testing Framework je nástroj nebo technologie používaná ve formě knihoven, API stejně jako grafického uživatelského rozhraní (GUI) pro sestavování požadavků a testu a také definování zátěže, která má být aplikována.
Existuje mnoho skvělých testing frameworků a Apache JMeter je jen jeden<\/EM> z nich. I když mají všechny podobný účel, mnohé z nich používají odlišné přístupy k terminologii určitých komponent a způsobu, jak vytvářejí test a aplikují zátěž. Některé dávají definici požadavků a transakcí do vlastních souborů s konfigurací krokové zátěže v jiném.
S Apache JMeter jsou všechny testovací objekty definovány v Test Plan a jsou logicky odděleny v rámci stromu.<\/P>Několik příkladů load testing frameworků:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Několik příkladů performance testing frameworků:<\/P>
wget<\/A>- Příkazový nástroj pro získávání jedné nebo více URL adres<\/LI>
- Může poskytovat podrobný přehled o každém požadavku a odpovědi<\/LI><\/UL><\/LI>
curl<\/A>
- Příkazový nástroj pro získávání jedné nebo více URL adres<\/LI>
- Může poskytovat podrobný přehled o každém požadavku a odpovědi<\/LI><\/UL><\/LI>
Fiddler<\/A>- GUI založený HTTP Debugger, který lze použít samostatně nebo s webovým prohlížečem<\/LI>
- Může poskytovat podrobný přehled o každém požadavku a odpovědi<\/LI><\/UL><\/LI><\/UL>
Testing Framework Architecture<\/STRONG><\/H5>Při testování ArcGIS Enterprise se většina architektonické pozornosti soustředí na škálovatelnost nasazovacích vrstev: Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase a Network Storage. Zatímco jeden 8 Core testovací stroj obvykle může odeslat dostatečné množství požadavků k uspokojení typického testu, někdy je potřeba více strojů, pokud aplikovaná zátěž vyžaduje vážný výkon.<\/P>V závislosti na použitých testing frameworkech mohou být některé testovací komponenty odděleny na různé stroje za účelem zlepšení škálovatelnosti test clienta<\/EM>.<\/P>Běžné komponenty pro škálování jsou:<\/P>Test ControllerJak název napovídá, hlavním úkolem controlleru je zastavit a spustit test a koordinovat sběr metrik testu od jednoho nebo více Test Agents<\/LI>V případě Apache JMeter je controller integrován přímo do GUI, ale také běží při spuštění testu z příkazového řádkuJiné testing frameworky mohou mít webové frontend Test Controlleru<\/LI><\/UL><\/LI>Obvykle je potřeba pouze jeden Test Controller pro dané testovací prostředí, ale může běžet na dedikovaném hardwaru odděleném od Test Agents<\/LI><\/UL><\/LI>Test AgentPrimárním úkolem Test Agenta je odesílat požadavky a přijímat odpovědi ze serveruTato komponenta vykonává většinu práce a vyžaduje nejvíce CPU zdrojů<\/LI><\/UL><\/LI>Pro velké úlohy může být potřeba více Test Agent strojů<\/LI>V případě Apache JMeter standardně běží Test Agent na stejném stroji jako Test Controller <\/LI><\/UL><\/LI>Test RepositoryStroj věnovaný ukládání výsledků load testu Toto může zahrnovat metriky testu jako doba odezvy, propustnost a využití hardwaru<\/LI><\/UL><\/LI>V případě Apache JMeter jsou výsledky ukládány na controller v textových (*.JTL) souborechJe možné posílat výsledky do databáze, ale není to výchozí nastavení<\/LI><\/UL><\/LI><\/UL><\/LI>Test VisualizationStroj používaný k vizualizaci metrik testu a využití hardwaru v reálném čase<\/LI>V případě Apache JMeter není GUI doporučeno pro vizualizaci dat produkčního testovacího běhu, ale příkazový řádek anoPokud jsou výsledky posílány do databáze, další software se může připojit k Test Repository pro vizualizaci informací<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Interactive Response Time Law<\/STRONG><\/H5>Interactive Response Time Law je vzorec definující vztah mezi klíčovými faktory výkonu, konkrétně uživateli, propustností, dobou odezvy a časem na přemýšlení uživatele. Výpočet lze uspořádat tak, aby určil parametr zájmu za předpokladu znalosti ostatních tří. Například pokud je znám počet uživatelů využívajících systém, průměrná doba odezvy požadavků a průměrný čas na přemýšlení uživatele, můžeme odvodit odhadovanou poptávku po propustnosti systému. Tento zákon je velmi užitečný při převodu uživatelů na propustnost a propustnosti na uživatele i v dalších případech použití a je základem oblastí souvisejících s testováním jako plánování kapacity.<\/P>Dán následující vzorec:
N = X * (R + Z)<\/P>N = Počet úloh nebo současných uživatelů
X = Propustnost za sekundu v systému
R = Doba odezvy nebo průměrný čas strávený úlohou v systému
Z = Čas na přemýšlení (Think time)<\/P>Pro více informací o Interactive Response Time Law viz:<\/P>http:\/\downloads.esri.com\/_Support\/_downloads\/_other_\/_ArcGIS%20Enterprise%20deployment%20guide_Scene%20layer%20benchmark%20testing.pdf<\/A>
