012345

}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky

Měření a ladění výkonnosti softwarových systémů Diplomová práce

Tomáš Hřebíček

Brno, podzim 2012

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Tomáš Hřebíček

Vedoucí práce: Ing. RNDr. Barbora Bühnová, Ph.D. ii

Poděkování Na tomto místě bych velmi rád vyjádřil své díky Ing. RNDr. Barboře Bühnové, Ph.D. za odborné vedení, cenné rady a čas, který mi věnovala.

iii

Shrnutí Diplomová práce se zabývá výkonností softwarového produktu jako jednou z klíčových charakteristik hodnocení úspěšného projektu. Práce se zabývá výkonností software jak po teoretické, tak praktické stránce. První část práce je věnována klíčovým softwarovým i hardwarovým parametrům ovlivňující výkon, a představuje taktiky a přístupy pro jeho ladění, kritéria hodnocení a pojem úzkého místa. V druhé části je pro ladění výkonu demonstrační aplikace využito nástrojů Apache JMeter a MS Visual Studio. Jsou detekována úzká místa a následně jsou odladěna. Zlepšení jsou prezentována zejména výstupy z nástroje Apache JMeter.

iv

Klíčová slova měření výkonu, software performance engineering, SPE, JMeter, Visual Studio, ASP.NET MVC, web performance

v

Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Cíle měření výkonu . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Měření výkonu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Profilování, monitoring, měření a testování software . . . . . . . . . 2.1.1 Testování a měření . . . . . . . . . . . . . . . . . . . . . 2.1.2 Profilování . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Parametry ovlivňující výkon . . . . . . . . . . . . . . . . . . . . . 2.2.1 Hardwarově orientované . . . . . . . . . . . . . . . . . 2.2.2 Softwarově orientované . . . . . . . . . . . . . . . . . . 2.2.3 Ostatní vlivy a jejich kombinace . . . . . . . . . . . . . 2.3 Kategorie testů . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Výkonnostní pohled . . . . . . . . . . . . . . . . . . . . 2.3.2 Jiné pohledy testů . . . . . . . . . . . . . . . . . . . . . . 2.4 Výsledky a výstupy měření . . . . . . . . . . . . . . . . . . . . . . 2.5 Zákonitosti vztažené k výkonu . . . . . . . . . . . . . . . . . . . . 2.5.1 Amdahlův zákon . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Analytické zákony o provozu systémů . . . . . . . . . . 2.6 Taktiky ladění výkonu . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Optimalizace kódu . . . . . . . . . . . . . . . . . . . . . 2.6.2 Strategie výpočtu . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Využití paralelismu . . . . . . . . . . . . . . . . . . . . . 2.6.4 Distribuování výpočtu . . . . . . . . . . . . . . . . . . . 2.6.5 Využití specializovaného hardware . . . . . . . . . . . 2.6.6 Vyvažování zátěže . . . . . . . . . . . . . . . . . . . . . 2.6.7 Využití kešování a mezipaměti . . . . . . . . . . . . . . 2.6.8 Prioritizace úloh . . . . . . . . . . . . . . . . . . . . . . 2.6.9 Škálování a změna architektury . . . . . . . . . . . . . . 2.7 Kritéria hodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 Hodnocení OLTP aplikací . . . . . . . . . . . . . . . . . 2.7.2 Hodnocení dávkových úloh . . . . . . . . . . . . . . . . 3 Metodiky a přehled nástrojů . . . . . . . . . . . . . . . . . . . . . . 3.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 UML profily pro modelování výkonu . . . . . . . . . . 3.2 Metodiky vývoje software zaměřené na optimalizaci a měření výkonu 3.2.1 Q-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Agilní metodiky . . . . . . . . . . . . . . . . . . . . . . . 3.3 Volně dostupné nástroje . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 The Grinder . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 3 3 3 3 3 3 4 5 5 5 6 7 8 8 8 9 11 11 11 11 11 11 12 12 12 12 13 13 14 15 15 15 16 17 19 21 21 24 vi

4

5

3.3.3 VisualVM . . . . . . . . . . . . . . . . . . . . . . . 3.4 Komerční nástroje . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 WebLOAD . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 LoadRunner . . . . . . . . . . . . . . . . . . . . . . 3.4.3 YourKit . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Nástroje vývojových prostředí . . . . . . . . . . . . . . . . . 3.5.1 NetBeans . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Microsoft Visual Studio . . . . . . . . . . . . . . . 3.6 Další nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 AppDynamics . . . . . . . . . . . . . . . . . . . . . 3.6.2 SeleniumHQ . . . . . . . . . . . . . . . . . . . . . 3.7 Vlastní prostředky . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Srovnání nástrojů . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Volně dostupné nástroje pro měření výkonu . . . 3.8.2 Komerční nástroje pro měření výkonu . . . . . . . Demonstrační aplikace . . . . . . . . . . . . . . . . . . . . . . 4.1 Specifikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Klíčové scénáře . . . . . . . . . . . . . . . . . . . . 4.2 Implementace, použité technologie a nástroje . . . . . . . . . . 4.2.1 Diagram tříd . . . . . . . . . . . . . . . . . . . . . 4.2.2 Projekty tvořící aplikaci . . . . . . . . . . . . . . . Aplikace nástrojů pro měření a ladění výkonu . . . . . . . . 5.1 Testovací prostředí . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Praktické srovnání JMeteru a nástrojů Visual Studia . . . . . 5.2.1 Nahrávání testu . . . . . . . . . . . . . . . . . . . . 5.2.2 Úprava a možnosti testu . . . . . . . . . . . . . . . 5.2.3 Výstupy z měření a možnosti jejich zpracování . . 5.2.4 Výsledné hodnocení a výběr primárního nástroje 5.3 Měřená funkcionalita a položky scénáře . . . . . . . . . . . . 5.3.1 Provádění měření . . . . . . . . . . . . . . . . . . . 5.3.2 Výsledky měření před úpravami . . . . . . . . . . 5.4 Hodnocení naměřených vlastností . . . . . . . . . . . . . . . 5.5 Aplikované techniky pro zvýšení výkonu . . . . . . . . . . . . 5.5.1 Použití kešování . . . . . . . . . . . . . . . . . . . . 5.5.2 Změna algoritmu . . . . . . . . . . . . . . . . . . . 5.5.3 Průzkum exekučního plánu . . . . . . . . . . . . . 5.5.4 Umístění databáze na SSD disk . . . . . . . . . . . 5.5.5 Nastavení Entity Frameworku . . . . . . . . . . . . 5.5.6 Použití komprese . . . . . . . . . . . . . . . . . . . 5.5.7 Svazování a minifikace skriptů a stylů . . . . . . . 5.5.8 Využití Content Delivery Network (CDN) . . . . . 5.6 Srovnání výkonu s počáteční implementací . . . . . . . . . . 5.6.1 Detekce maximálního počtu uživatelů . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 26 26 27 28 29 29 29 31 31 31 31 32 32 32 34 34 35 36 37 38 41 41 42 42 42 43 43 43 46 47 49 49 50 50 52 53 53 54 54 55 55 56 vii

5.6.2 Možnosti zisku dalšího výkonu . . . . . . . . . . . . . . 6 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Manifest Agilního vývoje software . . . . . . . . . . . . . . . . . . B Obsah databáze při založení . . . . . . . . . . . . . . . . . . . . . . C Snímky obrazovky profileru a testů z Visual Studia . . . . . . . . D Snímky obrazovky průběhu stahování stránky v Google Chrome E Obsah archivu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

57 58 61 62 63 64 68 70

viii

1 Úvod Výkonnost softwarového produktu je jednou z klíčových charakteristik hodnocení úspěšného projektu. Zanedbání požadavků na výkon ve specifikaci a vývoji software může vyústit v nepříjemné vyvrcholení snahy o dodání kvalitního produktu. Moorův zákon pojednává o zdvojnásobení výkonu hardware každý rok a půl, mohlo by se tedy nabízet jasné řešení – při dodání nevýkonného systému postačí počkat, později zakoupit hardware výkonější a vše bude v pořádku. Moorova zákona je ale využíváno i v software. Právě díky zrychlování hardware můžeme vytvářet stále komplexnější systémy nebo jednodušší nástroje pro vývojáře, které ale opět spotřebují výraznou část nového výkonu. Tyto vlastnosti tak mohou způsobovat pocit, že se subjektivní vnímání rychlosti software za poslední roky vlastně nezměnilo. Tohoto jevu si můžeme všimnout například i v prostředí webových stránek. Průměrná rychlost běžného internetového připojení domácnosti se v průběhu času jistě zvětšila, pocitově se však rychlost prohlížení moderního webu příliš nezměnila.

1.1

Cíle měření výkonu

Softwarové inženýrství se zaměřením na výkon (Software Performance Engineering, SPE) je systematický přístup k tvorbě softwarových systémů tak, aby splňovaly požadavky na výkon. Termín SPE vznikl v roce 1990 a za cíl má dále analyzovat výkon software po celou dobu jeho vývoje. Obor se zabývá více výkonem software než hardware, jelikož software je obvykle vyvíjen pro danou platformu. Úkolem SPE je zabývat se softwarem s cílem snížit složitost, optimalizovat strukturu a zvýšit tak výkon řešení na dané hardwarové platformě. Cílem měření výkonu by nemělo být pouhé změření aktuálního stavu, ale také analýza boucích potřeb z hlediska růstu nároků na aplikaci. Včasnou detekcí potenciálních úzkých míst systému lze předejít nespokojenosti zákazníků, ztrátě důvěryhodnosti a uživatelské nespokojenosti spojené se slabým výkonem poskytovaného systému nebo aplikace. Měření výkonu umožňuje kvalifikovaný odhad hranice SLA1 i chování systému v nestandardních podmínkách, jako jsou výpadky, přetížení či změny v konfiguraci. Motivací pro vývoj efektivnějších aplikací může být též finanční stránka systémů, zvláště pokud do jednoho rozpočtu patří jak nákup hardware, tak vývoj software. Vývoj dobře optimalizovaného software může pomoci ušetřit díky potřebě menšího počtu serverů a spojených nákladech (údržba, prostory, energie), ušetřené peníze se mohou investovat například do zaměstnanců. Proškolení zaměstnanci v příjemném pracovním prostředí mohou dále navyšovat kvalitu vyvíjených systémů. Mezi další oblasti týkající se výkonu aplikací patří například problematika spojená se spotřebou elektrické energie. Výzkum ohledně návrhu energeticky úsporných počítačových 1. SLA (Software Level Agreement) může být součást smlouvy nebo jiná forma dohody se zákazníkem, kde jsou definovány hranice, ve kterých je systém považován za funkční, doba odezvy zákaznické podpory a podobné informace [1].

1

1. Úvod systémů není zajímavý jen z pohledu stále více energeticky náročnějších datových center, ale také z pohledu mobilních zařízení, která mají omezenou kapacitu baterie.

1.2

Struktura práce

Druhá kapitola rozebírá ve svém začátku rozdíly mezi profilováním, monitoringem a měřením výkonu software. Uvedeny jsou dále klíčové parametry ovlivňující výkon jak z hlediska software, tak z hlediska hardware. Kapitola dále obsahuje popis různých typů testů, které se ve vývoji software vyskytují, a to jak z hlediska funkčních požadavků, tak z hlediska výkonu. Kapitola je zakončena vybranými zákonitostmi o výkonu software a kritérii hodnocení. Třetí kapitolu uvádí rozšíření jazyka UML pro anotaci modelů o výkonové parametry, zmíněny jsou obecné aktivity při vývoj software a vybrané metodiky s důrazem na výkon software. Tato část práce dále obsahuje popis několika volně dostupných i komerčních nástojů na měření výkonu software, včetně jejich srovnání. Visual Studio je použito také pro vývoj demonstrační aplikace, jenž je představena ve čtvrté kapitole. V úvodu této kapitoly je představena její specifikace a popis technologií zvolených pro implementaci. Další část kapitoly představuje řešení a vzhled aplikace, diagram tříd modelu a projekty, které výsledné řešení tvoří. Vývoj aplikace byl následovaný praktickou aplikací vybraných nástrojů pro měření výkonu a profilování. V páté kapitole je uvedeno testovací prostředí a měřící scénáře pro demonstrační aplikaci. Kapitola obsahuje přímé srovnání vybraného volně dostupného nástroje Apache JMeter s prostředky komerčního vývojového prostředí Visual Studio 2012 Ultimate. Dále jsou v této kapitole provedena některá měření výkonu, následované jejich zhodnocením. Pomocí měření jsou detekována úzká místa zvolené implementace a následně jsou odstraněna. Odladěná aplikace je znovu podrobena měření, jejichž výslekdy jsou následně srovnány s výsledky počáteční implementace.

2

2 Měření výkonu Nároky na výkon se různí dle typu systému, který chceme testovat, ladit či měřit. Pokud se jedná o OLTP (OnLine Transaction Processing) aplikaci, jejíž typickým zástupcem jsou e-shopy, budeme chtít dosáhnout především co nejlepší odezvy systému. U dávkových systémů půjde naopak o co největší počet zpracovaných dat (souborů, úkolů, faktur a podobně). Někde mezi těmito systémy jsou real-time a reaktivní systémy, u nichž nám jde zpravidla o dodržení času, do kterého musí systém nějakým způsobem zareagovat. Požadavky se obvykle liší i podle toho, zda se jedná o operační systém, middleware, nebo aplikační software.

2.1

Profilování, monitoring, měření a testování software

Při analýze výkonu software se obvykle používají tyto přístupy, často v pořadí, jak jej popisují následující podkapitoly. 2.1.1 Testování a měření K testování a měření software se přistupuje v momentě, kdy máme funkční nějaký celek aplikace a chceme změřit, jak se aplikace chová. Podrobněji se tomuto věnuje kapitola 2.3. Výstupem těchto aktivit může být označení úzkého místa v systému, například určitá komponenta nebo subsystém. Danou komponentu pak můžeme podrobit detailnější analýze, čímž přecházíme k profilování. 2.1.2 Profilování Jako profilování se označuje detailnější průzkum chování dané aplikace. Obvykle se zkoumá časová složitost volání jednotlivých funkcí, jejich paměťová náročnost, počet volání, hloubka zanoření zásobníku a další informace, které mohou vést k odhalení pomalé části software. Pomocí profilování tak můžeme snadněji určit kritické místo v aplikaci, způsobující největší zpomalení. Můžeme se například zaměřit na hledání často volaných funkcí a přezkoumat jejich implementaci, zda existuje možnost optimalizace nebo náhrada za rychlejší. 2.1.3 Monitoring Během testování systému nemusí dojít k odhalení úzkého místa, testování na určitých datech nebo kombinaci nastavení, které za ostrého provozu může způsobit zpomalení systému. Monitoringem je zde myšleno rozsáhlejší sledování výkonu systému po jeho nasazení, pomáhá odhalit neočekávané výkonnostní problémy.

2.2

Parametry ovlivňující výkon

Výkon počítačových systémů je ovlivňován mnoha faktory, zejména pokud jde o rozsáhlé systémy nasazené na více fyzických strojích a ještě více v případě rozložení přes více lokalit. 3

2. Měření výkonu 2.2.1 Hardwarově orientované Hardware poskytuje systémům hrubý výkon, je tedy jednou z nejdůležitějších součástí systémů. Mezi hlavní součásti ovlivňující výkon patří procesor (CPU), operační paměť (RAM), diskový subsystém, síťové spojení. Procesor Velikost výpočetní síly počítače určuje hlavně síla procesoru, především architektura, frekvence, počet jader, počet samotných procesorů, v případě některých modelů od společnosti Intel povolení Hyper-Threadingu1 , velikost vyrovnávacích pamětí a rychlost sběrnice. Operační paměť U pamětí platí pravidlo čím více, tím lépe. Rychlost a časování rozhoduje také, ale ne tak velkou měrou. Diskový subsystém V praxi se disky zapojují kvůli ochraně proti chybám i pro zvýšení rychlosti do diskových polí (RAID). Rozhodují nejen parametry jednotlivých disků, zejména počet otáček/min., vyhledávací čas, velikost vyrovnávací paměti, ale také typ a počet disků zapojených do výsledného pole. Rozhoduje také velikost vyrovávací paměti RAID řadiče. Mezi často používané typy zapojení patří 0 (prokládání), 1 (zrcadlení), 5 (1 paritní disk), s většími disky příchází ke slovu RAID 6 (2 paritní disky), případně jejich kombinace. Síť Zde rozhoduje rychlost, počet portů, z charakteristiky spojů pak zpoždění a rozptyl zpoždění (jitter). Více portů může být spřaženo do jednoho virtuálního síťového spoje. Při komunikaci mezi systémy rozhoduje, zda jsou na stejné podsíti, případně přes kolik aktivních prvků musí pakety cestovat. Konfigurace Vhodná konfigurace hardware pro danou aplikaci může výrazně zvýšit její výkon. Pro aplikaci, která pracuje převážně v jednom vlákně je vhodnější silnější procesor s méně jádry, než mnohojádrový o nižší frekvenci. Jiným aplikacím zase může vyhovovat jistý typ RAID zapojení a podobně.

1. Hyper-Threading je technologie na půli cesty mezi jednojádrovými a vícejádrovými procesory. Zdvojením části jádra procesoru se může jedno jádro jevit jako dvě logické jednotky [2].

4

2. Měření výkonu 2.2.2 Softwarově orientované Operační systém Přestože některé typy aplikací mohou být spustitelné na více platformách (typicky Java aplikace), může docházet k rozdílné výkonnosti při nasazení na určitý typ (Windows, Linux) nebo verzi daného systému. Databázový systém a jeho konfigurace Aplikace postavené nad databázemi mohou podávat jiné výkony při zvolení různých databázových systémů. Obdobná situace platí pro konfiguraci systému, kdy pomoci mohou indexy, vertikální či horizontální rozdělení tabulek a další optimalizace. Návrh a konfigurace systému Mezi nejdůležitější faktory ovlivňující výkon patří samotný návrh architektury aplikace a její nastavení pro danou platformu [3]. V době dostupných vícejádrových procesorů, a relativně levných pamětech, nemusí být výkonově optimální jednovláknová aplikace řešící veškerou logiku na pevných discích místo v paměti. Virtualizace Jistý vliv na výkon může mít i použití virtualizace, tzn. jestli operační systém, ve kterém je aplikace spuštěna, běží přímo na fyzickém hardware, nebo je spuštěn ve virtuálním prostředí. Mírné rozdíly pak může způsobit i zvolená virtualizační platforma. 2.2.3 Ostatní vlivy a jejich kombinace Na výkon systému v souvislosti s operačními systémy a procesory může mít přepínání kontextu, respektive plánovací strategie daného OS. Pokud je jednovláknová aplikace spuštěna na dvoujádrovém a jednojádrovém procesoru, může paradoxně podávat větší výkon na jednojádrovém procesoru. Ještě větší rozdíl pak může nastat v porovnání s dvouprocesorovým (jedno jádro na procesor) systémem. Za degradací výkonu stojí plánovací strategie operačního systému. Pokud je proces nucen být spouštěn část času na jednom jádru/procesoru a část času na druhém, musí se řešit přesun dat a stavu vykonávaného programu mezi výkonnými jednotkami. I z tohoto důvodu tak může mít vliv na výkon volba operačního systému. Je třeba pamatovat na to, že sebelepší aplikace nebude podávat dobrý výkon na pro ni nevhodném nebo zastaralém hardwaru, a naopak špatně navržená aplikace nebude podávat výborné výkony na kvalitním a rychlém stroji.

2.3

Kategorie testů

Podle přístupu můžeme testy používané při měření výkonu rozdělit do několika kategorií. Testy se ale nemusí striktně řadit do jedné kategorie, a tak na jeden test můžeme nahlížet z několika úhlů a řadit ho i do více kategorií. 5

2. Měření výkonu Při ladění a měření výkonu se používají především následující kategorie testů. Před samotným měřením těmito testy musí být alespoň měřená část aplikace funkční. Je třeba si uvědomit, že při testování výkonnosti není úkolem najít v software chyby, ale otestovat, jak se systém chová. Pokud testy měření výkonu mají příliš velkou funkční chybovost, výsledky nemusí být vůbec relevantní. Aby byly výslekdy měření použitelné, měli bychom mít jasno v tom, co od aplikace očekáváme. Podle typu aplikace tak naším cílem může být výkon pro obsloužení jistého počtu uživatelů současně, počtu zpracovaných úloh za určitý čas a podobně. Zapomenout bychom neměli ani na to, že aplikace může být sebelepší v jednom typu úkonu, ale naprosto nepoužitelná v úkonu jiném, například v závislosti na konfiguraci hardware na kterém běží. Občas je proto třeba mezi požadavky najít kompromis. Z výsledků měření výkonu také můžeme určovat hranice SLA. 2.3.1 Výkonnostní pohled Regresní testy Tento typ testů je používán ke sledování změn ve výkonu v důsledku změn v kódu. Pomáhá zjišťovat, zda změny v kódu nevyvolaly nepříznivé změny ve výkonu systému. Optimalizační a ladící testy Jsou používány při úsilí optimalizovat a ladit systémy tak, aby podávaly lepší výkon. Srovnávací výkonnostní testy Při použití s reálnými testovacími daty a nad srovnatelným hardwarem ukážou výkon očekávatelný při nasazení v produkčním protředí. Testy škálovatelnosti Ověřuje zda systém bude postupem času schopen zpracovávat větší zátěž. Tento typ testů je podobný zátěžovým testům. Klade na testovaný systém větší množství požadavků, za úkolem zjistit nejen zda dojde k jejich zpracování, ale také zda se systém nezhroutí. Zátěžové testy Při tomto testování se zkoumá chování systému, který je po dlouhou dobu zatěžován velkým počtem požadavků. Pomáhá odhalovat chyby, které se nemusí za normálního provozu (s průměrným počtem požadavků) projevit. Stress testy Tento typ testů zkoumá chování systému v extrémních podmínkách. Testuje se zejména jak se bude systém chovat v případě výpadku nějaké jeho části nebo částí. Zkouší se simulovat chybové stavy jako výpadek disku v poli a následný přepočet pole za plného chodu systému, 6

2. Měření výkonu výpadek databáze, síťového spojení a další možné jevy v závislosti na konfiguraci a návrhu systému. Testuje se také v kombinaci se zátěžovými testy (zvětšení počtu požadavků nebo dat ke zpracování). Kombinované techniky Samy o sobě tyto testy nemají tak vypovídající hodnotu, jako v jejich vhodné kombinaci. Obvykle se začíná s regresními testy, které pomohou odhalit výkon při běžných úkolech systému. Z těchto testů se později dají odvodit dalši testy, se zaměřením na konkrétní problém nebo funkcionalitu. Regresní testy také slouží jako určení výchozího bodu pro budoucí výkonnostní testy, ze kterých pak lze poznat, zda se výkon zlepšil, zhoršil, nebo na něj provedené úpravy nemají žádný vliv. Bez řádného provádění regresních testů může právě na základě nevhodných změn v kódu dojít k neodhalení zhoršení výkonu systému, respektive jeho zjištění až v pozdějších fázích projektu. Výsledky regresních testů se při vhodné interpretaci dají prezentovat zákazníkovi. Lze například ukázat, jak díky investicím do ladění kódu roste výkonnost. Odladěné regresní testy lze pak dále používat i v dalších kategoriích testování, stačí aplikovat přístup odpovícající tomu, co chceme zrovna měřit (například zvětšíme zatížení a máme testování škálovatelnosti, změníme dobu testování a máme zátěžový test, když k tomu ještě začneme odpojovat kabely ze switchů, vyndávat disky z polí a vypínat servery, máme stress testy). 2.3.2 Jiné pohledy testů Pro doplnění přehledu je uvedeno dělení z jiných pohledů na testování. Různé zdroje klasifikují testy různými způsoby, následující kategorie jsou jejich shrnutím. Jednotkové testy Jednotkové testy jsou určeny pro testování systému rozděleného na nejmenší funkční celky a používány jsou hlavně programátory pro ověření splnění požadavků. Testované části by měly být odříznuty od zbytku systému, aby se zamezilo vlivu chyb z ostatních částí. Metoda vývoje software zvaná Test Driven Development pak jednotkové testy používá jako určitou formu zadání požadované funkcionality. Integrační testy Pomocí těchto testů se ověřuje chováni a interakce jednotlivých komponent vyvíjeného systému. Výsledy by měly odpovídat analýze požadavků. Testy uživatelské přívětivosti Testy uživatelské přívětivosti zkoumají, jak je systém srozumitelný pro budoucí uživatele. Metodiky pro toto testování jsou různé, včetně použití speciálních laboratorních prostředí. 7

2. Měření výkonu Akceptační testy Těchto testů se může použít jako ověření spokojenosti zákazníka a mohou se skládat z testů funkční stránky, uživatelské přívětivosti, výkonu či dalčích požadavků, které se definují z pravidla v analýze požadavků. Neprovedení těchto testů při předání může později vést ke zbytečným sporům mezi zákazníkem a dodavatelem.

2.4

Výsledky a výstupy měření

Výstup z testování a měření komunikovaný zákazníkovi by měl obsahovat minimálně tyto údaje [4]: ∙

doba odezvy a propustnost klíčových scénářů,

∙

přesný popis prostředí, ve kterém byly prováděny testy, včetně –

informací o počtu a frekvenci procesorů, počtu jader, velikosti pamětí,

–

dále informací o diskovém subsystému, síťovém prostředí, operačních systémech a nainstalovaných opravných balíčcích,

–

nastavení hardware a software, které by mohlo mít vliv na výkon,

–

nastavení databáze, pokud je použita,

–

logů a výkonnostních zpráv, mezi které patří *

průměrné/maximální využití paměti,

*

vytíženost CPU (a jednotlivých jader),

*

délky front,

*

a další hardwarově orientované informace.

∙

Důležité je shrnutí o naměřených úzkých místech a směr, kterým se budou optimalizace dále ubírat.

2.5

Zákonitosti vztažené k výkonu

2.5.1 Amdahlův zákon Amdahlův zákon, pojmenován po počítačovém architektovi Genu Amdahlovi, byl poprvé představen v roce 1967. Používá se u víceprocesorových systémů, dnes můžeme říci vícejádrových procesorů. Předpovídá maximální teoretické zrychlení po přidání jader nebo procesorů ke stávajícímu hardware [5]. Lze jej adaptovat i pro komplexní systémy. Řekněme, že určitá komponenta se na výkonu celého systému podílí částí P, a že zrychlíme tuto komponentu o S. Například zdvojnásobením výpočetní síly části systému, která se podílí na výkonu z jedné čtvrtiny získáme 𝑃 = 0, 25 a 𝑆 = 2. Teoretické zrychlení systému označme I. 8

2. Měření výkonu Vzorec pro teoretické zlepšení výkonu systému je 𝐼 =

1 1−𝑃 +

𝑃 𝑆

.

(2.1)

Dosazením 𝑃 = 0, 25 a 𝑆 = 2 vyjde po zaokrouhlení číslo 1, 143, udávající maximální teoretické zrychlení o 14, 3 %. 2.5.2 Analytické zákony o provozu systémů Existuje několik dalších zákonitostí aplikovatelných na různé druhy systémů [6]. Počítají s pozorovatelnými atributy běžících systémů a nejsou příliš závislé na ničem jiném, než právě na těchto vlastnostech. Základem pro výpočty pomocí těchto zákonů jsou tyto atributy: ∙

𝑇 , doba, po kterou pozorujeme systém,

∙

𝐴, počet pozorovaných přijatých požadavků,

∙

𝐶, počet pozorovaných dokončených požadavků,

∙

𝐶𝑖 , počet pozorovaných dokončených požadavků ve zdroji 𝑖,

∙

𝐵, celková doba, po kterou je systém zaneprázdněn (𝐵 ≤ 𝑇 ),

∙

𝑁 , průměrný počet úloh v systému,

∙

𝑅, průměrná doba pobytu úlohy v systému. Z těchto atributů odvozujeme následující důležité veličiny:

∙

𝜆 = 𝐴/𝑇 , vstupní rychlost,

∙

𝑋 = 𝐶/𝑇 , propustnost,

∙

𝑈 = 𝐵/𝑇 , využití (0 ≤ 𝑈 ≤ 𝑇 ),

∙

𝑆 = 𝐵/𝐶, průměrná doba obsluhy pro dokončenou úlohu,

∙

𝑆𝑖 , doba obsluhy úlohy ve zdroji 𝑖,

∙

𝑊 = 𝑅 − 𝑆, průměrná doba pobytu úlohy ve frontě,

∙

𝑉𝑖 = 𝐶𝑖 /𝐶, počet požadavků úlohy na zdroj 𝑖,

∙

𝐷𝑖 = 𝑆𝑖 · 𝑉𝑖 , celková doba obsluhy úlohy ve zdroji 𝑖.

Zákon využití prostředku Využití se rovná součinu propustnosti a střední doby obsluhy. 𝑈 =𝑋 ·𝑆

(2.2)

Díky tomuto zákonu můžeme mimo jiné určit maximální propustnost daného zdroje. Například zdroj, který průměrně zpracuje 1 úlohu za 200 ms velmi těžko dosáhne propustnosti větší než 𝑋 = 1/0, 2 = 5 úloh za sekundu. Pokud navíc víme, že využití tohoto zdroje je 𝑈 = 0, 5, celková propustnost bude přibližně 𝑋 = 5 · 0, 5 = 2, 5 úlohy za sekundu. 9

2. Měření výkonu Littlův zákon Průměrné množství úloh v systému se rovná součinu propustnosti systému a průměrnému času, který úloha v systému stráví. 𝑁 =𝑋 ·𝑅

(2.3)

Příklad: máme zdroj, jehož průměrná fronta úloh je 𝑁 = 5 a je schopen zpracovat 𝑋 = 20 úloh za sekundu. Průměrná doba pobytu úlohy v daném zdroji je 𝑅 = 5/20 = 0, 25 sekund. Littlův zákon může být opět aplikován jak na úrovni jednotlivých zdrojů, tak na úrovni celého systému nebo subsystému. Při výpočtech pak musíme uvažovat hodnoty naměřené pro danou část (systém, subsystém, zdroj). Zesílený zákon toku Propustnost i-tého zdroje se rovná součinu propustnosti systému a počtu návštěv v tomto zdroji. 𝑋𝑖 = 𝑋 · 𝑉𝑖

(2.4)

Zesílený zákon toku se týká vztahu mezi součástmi systému, propustnost systému musí být úměrná propustnosti jeho součástí. Pokud nějaká úloha požaduje prostředky nějakého zdroje, a chceme, aby propustnost systému byla zachována, musí daný zdroj poskytovat propustnost úměrnou zvětšování požadavků na systém. Zákon využití i-tého zdroje Využití zdroje se rovná součinu jeho propustnosti a průměrné potřebě tohoto zdroje. 𝑈𝑖 = 𝑋𝑖 · 𝑆𝑖 = 𝑋 · 𝐷𝑖

(2.5)

Díky tomuto zákonu můžeme definovat pojem úzkého místa (bottleneck). Pojem úzkého místa označuje zdroj v systému, nebo subsystém, který má největší dopad na výkon systému jako celku. Využití každého zdroje je v rozmezí 0 ≤ 𝑈𝑖 ≤ 𝑇 , takže platí (∀𝑖)𝑋 · 𝐷𝑖 ≤ 1. Tento vztah může být vyjádřen též jako (∀𝑖)𝑋 ≤ 1/𝐷𝑖 . Označme 𝐷𝑚𝑎𝑥 = 𝑚𝑎𝑥𝑖 {𝐷𝑖 }, nyní můžeme poslední nerovnost vyjádřit jako vztah 𝑋 ≤ 1/𝐷𝑚𝑎𝑥 . To znamená, že propustnost systému 𝑋 je shora omezena nepřímo úměrně zdroji s maximálním množstvím požadavků 1/𝐷𝑚𝑎𝑥 . Největší doba strávená jednou úlohou v daném zdroji 𝐷𝑚𝑎𝑥 nám dává zdroj s minimální propustnostní v systému 1/𝐷𝑚𝑎𝑥 . Z toho vyplývá, že propustnost celého systému nemůže být větší než propustnost zdroje s minimální propustností, tím pádem detekujeme úzké místo v systému. Pokud dopředu známe požadavky na systém, díky této úvaze lze úzká místa detekovat dříve. Zvýšením výkonu části systému, která se jeví jako úzké místo, můžeme zvýšit celkový výkon systému za předpokladu, že žádná z dalších součástí systému není blízko své hranici výkonu. V takovém případě vyřešíme jedno úzké místo, ale záhy detekujeme jiné. Hluboké a formálně uchopené analýze tohoto problému se věnuje například teorie front. 10

2. Měření výkonu

2.6

Taktiky ladění výkonu

Díky znalosti úzkého místa v systému můžeme přejít k jeho odstranění nebo alespoň zmírnění dopadu na celkový výkon. Dle rozsahu úzkého místa se nabízí různé možnosti řešení [3]. 2.6.1 Optimalizace kódu Optimalizace kódu je pokus o odstranění úzkého místa v nejjemnějším detailu. Díky profilovacím nástrojům různého typu lze odhalit metody a funkce, které při zpracování požadavku trvají nejdelší dobu, případně jsou volány nejčastěji. Optimalizace těchto míst může mít kladný vliv na dobu zpracování požadavku. Příkladem neoptimálního kódu je například využívání výjimek pro řízení toku programu, nevhodně zapsaná posloupnost podmínek či přílišné používání skoků v programu. 2.6.2 Strategie výpočtu Ke stejnému výsledku mohou vést různé strategie výpočtu, můžeme využít různých knihoven implementujících tutéž funkcionalitu a podobně. Srovnáním různých strategií a volbou vhodné metodiky pro konkrétní hardware můžeme mnohé získat. Výpočty nad daty z databáze je například téměř vždy mnohem efektivnější provádět přímo v databázovém stroji, oproti načítání objektů z databáze do paměti a provádění výpočtů až v kódu. 2.6.3 Využití paralelismu Pokud úloha může být paralelisována a máme dostatek systémových prostředků, můžeme ji rozdělit na dílčí úlohy, které necháme vypočítat souběžně. Tímto krokem můžeme značně snížit celkovou dobu výpočtu. Použití paralelismu nelze aplikovat v každé situaci, některé úlohy rozděleny být nemohou, například pokud na sobě závisí průběžné výsledky. V jiných případech můžeme být limitováni výkonem procesoru a využití tohoto kroku by mohlo vést i k opačnému efektu – zhoršení odezvy z důvodu vyšší režie. 2.6.4 Distribuování výpočtu V rozsáhlejších prostředích je maximalizováno využití paralelismu díky distribuování úkolů mezi více výpočetních jednotek. U této techniky je opět nutné zvážit, zda přinese zlepšení, nebo režie spojená s přenosem úkolů po síti na jiné výpočetní jednotky celkovou dobu zpracování úlohy nezvýší. 2.6.5 Využití specializovaného hardware Některé typy výpočtů mohou být značně urychleny, pokud pro ně lze vyvinout specializovaný hardware. U osobních počítačů se tohoto využívá například v podobě grafické karty. Specializace těchto karet na generování grafického výstupu umožňuje optimalizovaný návrh již na úrovni hardware. Procesor je pak určen pro obecné výpočty. 11

2. Měření výkonu Výkonu grafických karet se v poslední době začalo využívat i v oblasti superpočítačů. Každá výpočetní jednotka nejrychlejšího superpočítače na světě Titan (k 12.12.2012) je tvořena i specializovanou grafickou kartou od společnosti Nvidia [7].

2.6.6 Vyvažování zátěže Vyvažování zátěže (load balancing) je strategie podobná distribuovaným výpočtům s tím rozdílem, že výpočet jednoho požadavku je řešen jednou jednotkou. Různé požadavky ale mohou putovat na různé jednotky. Load balancing lze řešit na více úrovních, ať už pomocí softwarového load balanceru či specializovaného hardware. Příkladem softwarového vyvažování zátěže může být implementace round-robin v protokolu DNS, kdy DNS server na stejný dotaz odpovídá postupně jinou odpovědí. Díky kešování dotazů na cílové stanici tato stanice komunikuje pouze s tímto serverem až do vypršení platnosti DNS odpovědi.

2.6.7 Využití kešování a mezipaměti Kešování se využívá v mnoha úrovních, počínaje kešemi v procesorech, vstupně-výstupních zařízeních, diskových polích na straně hardware a kešování výsledků na straně software. Zamezení výpočtu stejné úlohy vícekrát a ukládání výsledků do mezipaměti může znatelně zvýšit výkon celého řešení. Ukládat se mohou výsledky dílčích výpočtů nebo celých požadavků. Kešování může být použito na více úrovních jak na straně serveru, tak klienta. Ponechání některých dat v paměti místo jejich opětovém načítání při každém požadavku může též znatelně zvýšit výkon.

2.6.8 Prioritizace úloh V případě, že systém řeší různé typy úloh s různou důležitostí nebo požadovanou dobou odezvy lze tyto úlohy řadit do různých kategorií. Každá kategorie pak může mít vlastní frontu požadavků s přidělením většího času obsluhy pro fronty s vyšší prioritou. Prioritizovat lze opět na více úrovních, počínaje datovými toky na úrovni protokolů TCP/IP nebo nastavením priority daných procesů na úrovni operačního systému.

2.6.9 Škálování a změna architektury Pokud žádná z předchozích technik neposkytne požadovaný výkon, bude pravděpodobně nutné buď zakoupit výkonnější hardware, nebo změnit architekturu systému. Ke škálování systému můžeme použít v zásadě dvě strategie. První z nich, označována anglickou kolokací Scale-Up, označuje použití stejné architektury, pouze s rozdílem použití silnějšího hardware (více procesorů, větší paměť, rychlejší diskové pole a podobně). Druhou možností je pak Scale-Out, pod níž se mohou skrývat i změny v architektuře za účelem rozložení zátěže na více prvků. Tato technika se dá chápat jako určitá forma vyvažování či distribuování zátěže na více serverů. 12


2.7

Kritéria hodnocení

Situace vždy není tak jednoduchá, jak by se mohlo zdát z posledního zákona. Systém může mít řadu úzkých míst, která nepůjde snadno detekovat. Například [8] se věnuje problematice souběžných úzkých míst, kdy se systém na první pohled jeví jako nesaturovaný (žádná z komponent nedosáhla svého výkonového maxima), ale výkon se již dále nezvyšuje. Z pohledu uživatele nebo zadavatele softwarového systému nám téměř vždy půjde o dodržení smluvních podmínek. Použitelnost výsledného systému nebo aplikace odpovídající určení systému je jedním z klíčových vlastností úspěšného projektu. Kritéria se obvykle definují ve smlouvě a jsou ověřována při předávacích testech, případně již během vývoje. Navzdory intuitivnímu požadavku po maximálním využití všech komponent systému je tento přístup nevhodný. Velice výjimečně totiž budou nároky na systém jednotvárné. Mnohem obvyklejší jsou nároky proměnné v závislosti na pracovní době nebo úlohách, které se v daný čas plní (fakturace ke konci zúčtovacího období, noční kompilace projektů, přepočty dat a podobně). Dále může být požadováno zajištění redundance, aby při dočasné nefunkčnosti části sytému nemuselo dojít k jeho odstavení. Kdyby byl takový systém konstruován na běh pod plnou zátěží, této funkce bychom z definice nemohli dosáhnout. Argumentem pro návrh jistých rezerv pro provoz systému také může být rychlejší opotřebení hardware při velmi dlouhodobé zátěži (zejména disků). Z těchto důvodů se systémy z pravidla nenavrhují na běh pod plnou zátěží. 2.7.1 Hodnocení OLTP aplikací Jelikož testování OLTP aplikací zahrnuje chování uživatele, hlavním měřítkem u měření výkonu těchto aplikací je doba odezvy vnímaná uživateli. Z pohledu uživatele se odezva začíná počítat od okamžiku vznesení požadavku na systém (například kliknutí na odkaz na webové stránce) až po získání odpovědi. Do tohoto časového úseku se započítává latence sítě, doba zpracování požadavku na serveru a nakonec i čas zobrazení výsledku webové stránky prohlížečem. Tato úvaha nám dává dvě proměnné – dobu, po kterou je požadavek uživatele skutečně zpracováván na serveru, označme ji 𝑇𝑟 , a dobou přemýšlení, která je časem mezi dvěma požadavky na server od jednoho uživatele, označme ji 𝑇𝑡 . Veškeré nástroje popisované v kapitole 3.3 a dalších poskytují možnost nastavit dobu přemýšlení a simulovat tak reálné chování uživatele. Rozdíl mezi dobou odezvy a časem přemýšlení pak vede k rozdílu mezi aktivními uživateli 𝑁𝑎 a uživteli, kteří mají požadavky na systém souběžně 𝑁𝑠 . Ze vzorce 2.6 je patrný rozdíl mezi aktivními a souběžnými uživateli. Aktivních uživatelů s nenulovou dobou přemýšlení bude vždy více, než souběžných uživatelů. 𝑁𝑠 = 𝑁𝑎

𝑇𝑟 𝑇𝑟 + 𝑇𝑡

(2.6)

Při analýze požadavků je proto u používání termínu uživatel být obezřetný a vysvětlit zákazníkovi rozdíl mezi aktivními a souběžnými uživateli. 13


Obrázek 2.1: Vztah doby přemýšlení, aktivních a souběžných uživatelů. V tabulce 2.1 a souvicejícím obrázku s grafem 2.1 je vidět vztah aktivních a souběžných uživatelů při zachování doby odezvy do 2 sekund. Dále je zvyšován čas přemýšlení. Příklad v tabulce: při průměrném čase přemýšlení 60 sekund a 200 aktivních uživatelích musí systém zvládat alespoň 7 souběžných uživatelů, aby byla zachována požadovaná doba odezvy menší než 2 sekundy.

Čas přemýšlení (s)

180 120 60 20 10

20 1 1 1 2 4

Počet aktivních uživatelů 50 100 200 500 1000 1 2 3 6 11 1 2 4 9 17 2 4 7 17 33 5 10 19 46 91 9 17 34 84 167

Tabulka 2.1: Zdrojová tabulka pro graf vztahu uživatelů 2.1.

2.7.2 Hodnocení dávkových úloh Na rozdíl od aplikací v přímém kontaktu s uživateli (jako jsou aplikace typu OLTP), u dávkových úloh je situace mnohem jednodušší. Tyto úlohy mají obvykle za úkol zpracovat nějaká data a cílem zhodnocení výkonu je rychlost zpracování dat, tedy propustnost. Příkladem takové úlohy může být noční dávka zpracovávající nějaká data (faktury, logy, ...). Měřítkem pak je počet zpracovaných objektů za jednotku času.

14

3 Metodiky a přehled nástrojů 3.1

UML

Unified Modeling Language (UML) [9] je velice populární nástroj (jazyk) pro modelování, grafickou reprezentaci, dokumentování a návrh softwarových systémů. Poskytuje objektový přístup k analýze a návrhu modelovaného systému, nikoliv však metodiku vývoje. Proto lze modely vytvořené v UML používat napříč metodikami vývoje softwarových systémů. UML je považováno za modelovací standard, aktuální verze je 2.4.1. Mezi základní diagramy ze sady UML patří diagram případů užití, diagram tříd, sekvenční a komunikační diagramy, diagram nasazení nebo diagram aktivit. Známým komerčním nástrojem pro modelování je Visual Paradigm for UML [10], z volně dostupných lze zmínit StarUML [11]. 3.1.1 UML profily pro modelování výkonu UML lze přizpůsobovat pomocí takzvaných profilů [12]. Této vlastnosti bylo využito i v případě modelování výkonnosti softwarových systémů, pro které vznikl profil zvaný UML Profile for Schedulability, Performance and Time (SPT) [13]. Tento profil byl reakcí na absenci prostředků pro modelování real-time systémů v UML. Postupem času (myšleno i před vznikem SPT profilu) vzniklo množství jiných přístupů jak modelovat výkonnost. Úmyslem SPT profilu není svázat analytikům a systémovým inženýrům ruce, aby používali pouze tento nástroj, ale poskytnutí společného flexibilního základu, který je možno specializovat. Důraz při návrhu tohoto profilu byl kladen zejména na modelování času a časově závislých jevů, které jsou klíčové pro modelování výkonnosti a plánování. Základním cílem této specifikace je vytvoření nástroje pro predikci chování systému na základě analýzy softwarových modelů – zvláště před napsáním jakéhokoliv kódu. Modelování výkonnosti tak přispívá k odhalení problémů v časných fázích projektu, čímž dojde k ušetření času a práce při jejich opravách, na rozdíl od zjištění těchto defektů po návrhových či implementačních fázích, nebo nejhůře – při akceptačních testech. SPT profil není novou analytickou technikou, nýbrž umožňuje anotovat UML modely takovým způsobem, aby současné či budoucí analytické techniky mohly této funkce využít. Další výhody, které SPT profil přináší, je usnadnění komunikace mezi vývojáři obdobnou cestou, jakou jsou již zvyklí komunikovat, a dále interoperabilita mezi různými analytickými nástroji. Nástupcem SPT pofilu je UML Profile for Modeling and Analysis of Real-time and Embedded Systems (MARTE) [14]. Tento profil se ještě více zaměřuje na real-time a embedded systémy1 . MARTE profil zachovává vlastnosti zavedené v SPT profilu, mezi které patří interoperabilita mezi nástroji, poskytování obecného přístupu k modelování hardwarových a softwarových vlastnostní systémů za účelem lepší komunikace mezi vývojáři, umožnění 1. Embedded systémy jsou jednoúčelové systémy zabudované do nějakého zařízení. Jako příklady lze uvést herní konzole, kalkulačky, zdravotnická zařízení, mobilní telefony, síťové prvky a podobně.

15

3. Metodiky a přehled nástrojů tvorby modelů použitelných ke kvantitativní analýze a předpovídání chování systémů s ohledem na vlastnosti hardware a software.

3.2

Metodiky vývoje software zaměřené na optimalizaci a měření výkonu

Metodika vývoje software je sada zásad a aktivit určitého směru vedoucí k dosažení cíle, tedy hotového softwarového systému. Metodik je celá řada, liší se zejména v pořadí implementace částí systému, hlavních aktivit, které tým nebo lidé v určitých funkcí v průběhu vývoje provádí, modelů a prototypů, které se používají a podobně. Typické fáze, které obsahuje většina metodik jsou následující. 1

Analýza (specifikace požadavků)

2

Návrh

3

Implementace

4

Testování (předání)

5

Údržba

Cílem každého přístupu k vývoji software je odhalit chyby co nejdříve, aby mohly být odstraněny pokud možno s co nejnižšími náklady. Stejný přístup by se měl týkat i odhalování problémů s výkonem, a tak již během specifikace požadavků a analýzy by měly zaznít požadavky týkající se očekávaného počtu současných uživatelů, rychlostí odezvy a dalších parametrů důležitých pro použitelnost software zákazníkem.

Specifikace požadavků a analýza Během těchto fází se specifikují požadavky na funkcionalitu systému včetně podmínek a omezení jeho bezproblémového provozu. Výsledkem analýzy by měl být dokument detailně popisující požadovaný systém, který vznikne na základě rozhovorů analytiků se zadavatelem a nejlépe jeho zaměstnanci a lidmi, kteří nový systém budou používat. Z výkonnostního pohledu by pak měly být detekovány požadavky zmíněné výše, tedy očekávaný počet uživatelů, garantovaná rychlost odezvy, očekávané dlouho běžící úlohy a náročnost na jejich zpracování.

Návrh a vývoj software Během této fáze vzniká produkt založený na výsledcích analýzy. Zpočátku se v této fázi typicky používají zejména testy na ověření správnosti funkcionality. Jakmile je funkční nějaká část systému, je možno se zaměřit i na zlepšování výkonu a spouštět regresní a optimalizační testy. V pozdějších fázích a dokončenosti projektu jsou používány testy škálovatelnosti a zátěžové testy. 16

3. Metodiky a přehled nástrojů Testování a předání Úkolem této fáze je odladit systém a ukázat zákazníkovi, že splňuje cíle zadané ve specifikaci požadavků. Dále se v této fázi projektu pokračuje s testováním škálovatelnosti, spuští se zátěžové a stress testy.

3.2.1 Q-Model S metodikami a aktivitami během vývoje software je často spojován takzvaný V-Model. Tento model zjednodušuje pochopení procesů během vývoje softwarového systému a ukazuje jednotlivé aktivity a jejich vztahy v závislosti na fázi a projektu. Levá strana ukazuje systémovou dekompozici, pravá integraci. Obrázek 3.1 ukazuje návaznost jednotlivých fází, zejména pak provázanost implementačních a návrhových aktivit (například detailní návrh je ověřován jednotkovými testy). Z hlediska výkonnosti systémů lze V-Model chápat také. Například požadavky na výkon definované ve specifikaci software se mohou ověřovat v systémových testech, tedy nechápejme testy jako striktně funkční testování, můžeme testovat i nefunkční požadavky – ergonomii systému, výkonnost atd.

Obrázek 3.1: V-Model. Důsledněji se rozšíření V-Modelu o výkonnostní požadavky věnují v [6], kde je navrženo rozšíření modelu nazvané Q-Model. Na obrázku 3.2 se jedná o střední část. Toto rozšíření v sobě zahrnuje i činnosti spojené s verifikací a testováním výkonu jak během vývoje, tak i v pozdějších fázích projektu. 17

Obrázek 3.2: Q-Model, zdroj: [6].

3. Metodiky a přehled nástrojů

18

3. Metodiky a přehled nástrojů 3.2.2 Agilní metodiky Agilní metodiky vývoje software jsou reakcí na tradiční metody plánovaného vývoje software. Na rozdíl od tradičních přístupů agilní vývoj spoléhá spíše na zaměstnance a jejich kreativitu, než na zavedené procesy. V roce 2001 se sešlo několik velikánů v oboru vývoje software (například Martin Fowler, Kent Beck, Ken Schwaber, Bob Martin, Dave Thomas, Jess Sutherland), z čehož vzešel tzv. Manifest Agilního vývoje software (kompletní znění a zdroj viz příloha A). V manifestu se uvádí, že by měl agilní vývoj upřednostňovat, respektive se zaměřit na čtyři základní vlastnosti: ∙

jednotlivce a interakci před procesy a nástroji,

∙

fungující software před vyčerpávající dokumentací,

∙

spolupráci se zákazníkem před vyjednáváním o smlouvě,

∙

reagování na změny před dodržováním plánu.

Review [15] sumarizující zkušenosti s agilními metodikami poukazuje na vhodnost použití i u nezkušených týmů. Extrémní programování Extrémní programování (XP) je jednou z metodik implementovaných v duchu Manifestu Agilního vývoje software. Zaměřuje se na krátké vývojové cykly a spokojeného zákazníka. XP bylo vytvořeno Kentem Beckem během jeho práce na projektu ve společnosti Chrysler, kde se stal vedoucím projektu a začal upravovat používanou vývojovou metodiku. Ačkoliv byl projekt zrušen, Beck na základě zkušeností s úpravou metodiky vydal v roce 1999 knihu Extreme Programming Explained [16]. V této knize je popsáno XP jako metodika vývoje zaměřená na vývoj kvalitního software. Extrémní programování uzává těchto 5 hodnot: Respekt, Komunikace, Jednoduchost, Zpětná vazba, Odvaha. Vývoj software vyžaduje komunikaci specifikace vývojářům. V klasických metodách vývoje jsou požadavky a specifikace komunikovány pomocí dokumentace. Extrémní programování upřednostňuje přímou komunikaci mezi vývojáři. XP podporuje začínat s tím nejjednodušším řešením a postupně ho rozvíjet. Rozdíl mezi klasickými metodami je v také v zaměření vývoje na části, které jsou potřeba nyní. Návrh a implementace částí, které budou potřeba v budnoucnu může vyústit ve zbytečnou práci na věcech, které se nakonec nevyužijí či nebudou potřeba. Název metodiky říká, že pokud se během vývoje ukáže jako užitečné často testovat, je třeba dotáhnout to do extrému. Pokud se vyplatí často dělat schůzky se zákazníkem, nejlepší je mít jednoho přímo v místě vývoje systému. Zajímavou vlastností této metodiky je programování v párech, kdy jeden z dvojice píše kód a druhý působí jako pozorovatel, sleduje myšlenky písaře a případně je koriguje a konzultuje. Programátoři v těchto dvojicích si často vyměňují své pozice, vhodné je také měnit složení dvojic. Vývoj v tomto stylu přispívá ke kolektivní zodpovědnosti, výhodným benefitem je i rychlejší zaškolení nových zaměstnanců. 19

3. Metodiky a přehled nástrojů Vztah extrémního programování k testování výkonu je velmi příznivý. XP říká, že jednoduchý návrh často vede k výbornému výkonu. Doporučena je průběžná integrace a automatizované spouštění testů. K zajištění vysoké kvality je vhodné psát unit testy ve stylu metodiky zvané Test Driven Development. Kombinace průběžné integrace a množství testů nabízí generování výstupů se seznamem defektů. Takto rychlá odezva pomáhá vývojářům opravit nalezené chyby rychleji a lépe. Zajímavý je také fakt, že používání agilních metodik, zejména XP, pomáhá zvyšovat spokojenost zaměstnanců a přináší pocit vysoké produktivity. Shrnutí všech výhod i nevýhod lze nalézt ve zmíněné přehledové studii. Abychom neuváděli jen samá pozitiva, je třeba zmínit, že agilní přístupy se velice těžko uplatňují v rozsáhlých projektech. U párového programování je problém v případě, že se členové dvojice výrazně liší ve svých schopnostech. Práce celé dvojice tak může být zpomalena. S tímto může souviset i menší zastupitelnost členů týmu oproti klasickým metodám vývoje, jak je uvedeno například v [15]. Test Driven Development TDD je zvláštní způsob vývoje software s vysokým zaměřením na psaní automatizovatelných testů. Testy jsou napsány ještě před psaním samotného kódu programu a můžou sloužit i jako specifikace. Výhodou tohoto přístupu je možnost opakovaně spouštět již napsané testy a ověřovat tak i funkcionalitu, která byla před nějakou úpravou považována za funkční (regresní testování). Postup vývoje pomocí TDD je tedy následující: 1

napsání několika automatizovaných testů,

2

ujištění se, že tyto nové testy při spuštění selžou (jelikož zatím není co testovat),

3

implementace testovaných součástí, ujištění se, že nyní nové testy projdou,

4

periodické spouštění všech testů, například každou noc (regresní testování).

Díky TDD je programátor zaměřen vždy na menší kus vyvíjeného software a lépe tak udrží koncentraci a přehled nad prací. Pokud tentýž programátor implementuje testy i produkční kód, TDD obvykle vede k lepšímu návrhu testů, neboť díky tomu, že jsou napsány ještě před implementací produkčního kódu, nejsou psány se znalostí implementace tohoto kódu a testovaný produkt je brán jako černá skříňka. Tento přístup obvykle vede k dřívějšímu odhalení většího množství chyb a tím pádem efektivnějšímu vývoji. De facto standardem pro TDD je testování pomocí jednotkových testů (unit testy) a jejich implementace příslušná použitému jazyku (jUnit – Java, NUnit – .net). Výstupem TDD je značné množství testů, ve srovnání na počet řádků i rovnající se počtu řádků samotného programu. Tyto testy jsou pak cennou součástí celého projektu. Studie v prostředí IBM srovnávající zkušený tým, který nepoužíval žádného řízeného přístupu k testování a tým nováčků striktně dodržujících principy TDD ukázal, že použitím TDD lze dosáhnout kvalitních výsledků i u nezkušeného týmu. V tomto případě dokonce lepších, než týmu zkušených lidí [17]. 20


3.3

Volně dostupné nástroje

3.3.1 JMeter Apache JMeter [18] je volně dostupná desktopová aplikace vyvíjená na platformě Java, určená pro zátěžové testy a měření výkonu aplikací. Původně byla navržena pro testování webových aplikací, ale její funkcionalita byla postupně rozšířena. Momentálně lze pomocí této aplikace testovat různé druhý systémů, počínaje jednoduchými statickými stránkami, ať už přes protokol HTTP, nebo zabezpečený HTTPS. Mezi další možnosti patří testování dynamických stránek, webových služeb, databází přes rozhraní JDBC, JMS systémů, LDAP serverů, emailových serverů přes protokoly IMAP(S), POP3(S), SMTP(S) a dalších služeb. V samotném programu lze generovat grafické výstupy naměřených dat. Aplikaci lze rozšiřovat o vlastní součásti. Vývoj testů v JMeteru probíhá formou grafického rozhraní, kdy se pomocí stromové struktury definuje pořadí prováděných úkonů a nastavení jejich parametrů. Výhodou tohoto řešení je snadná definice globálního nastavení a jednoduché nahrazení za nastavení jiné. Testy lze také nahrávat pomocí konfigurace JMeteru jako proxy serveru2 .

Obrázek 3.3: Apache JMeter s používaným scénářem ladění a měření výkonu. 2. Proxy server funguje jako článek mezi klientem a cílovým serverem. Přijímá požadavky od klienta a vůči serveru sám vystupuje jako klient. Odpovědi odesílá zpět na klienta.

21

3. Metodiky a přehled nástrojů Konfigurace probíhá pomocí elementů různých typů, kdy vždy nastavení aplikované výše ve stromové struktuře je obecnější, než nastavení aplikované níže. V horních patrech se tak určí například adresa testovaného serveru, v nižších patrech pak už pouze relativní adresa k měřenému zdroji. Použitelné elementy v měřících scénářích JMeteru lze rozdělit do několika kategorií. Skupiny vláken Skupiny vláken jsou základním stavebním kamenem každého testu. Pomocí tohoto konfiguračního elementu se definuje počet virtuálních uživatelů, postup jejich náběhu a počet průchodů. Controllery Pomocí prvků tohoto typu se určuje průchod testem. Každý typ controlleru reprezentuje různé chování, příkladem můžou být ForEach (projde všechny podčásti), If (provádí podčásti na základě nějaké podmínky), Interleave (každou iteraci testu vybírá postupně jeden prvek ze svých podčástí – simulace různých průchodů), Only Once (prováděný pouze jednou za běh testu – vhodný pro simulaci přihlášení), dále pak Switch, Random nebo Loop controllery, chování opět odpovídá jejich názvům. Konfigurační prvky Do této kategorie patří prvky, které nastavují nějaké vlastnosti běhového prostředí JMeteru, hodnoty uživatelsky definovaných proměnných nebo výchozí vlastnosti dané skupiny testů. V případě webových aplikací tu jsou prvky pro podporu cookies, HTTP hlaviček nebo kešování. Časovače Časovače jsou určeny k simulaci času přemýšlení u reálných uživatelů. K dispozici je několik druhů, například konstantní časovač (generuje vždy stejné zpoždění) nebo časovač založený na Poissonově rozdělení. Pre- a Post-processory Pomocí těchto elementů lze předzpracovat, nebo naopak zpracovat až výsledek z komponenty typu vzorkovač (Sampler). Výsledky lze zpracovávat například pomocí XPath dotazu, nebo regulárních výrazů. Vzorkovače Nejdůležitější element, v podstatě výkonná část celého testu. Pomocí elementů typu vzorkovač se udává, co se bude testovat a měřit. Typy odpovídají specifikovaným protokolům, najdeme zde tedy například FTP, HTTP, JDBC, LDAP požadavek a mnoho dalších. Testy Elementy typu Assertion testují hodnoty proměnných různého typu. Jmenovat lze například test velikosti odpovědi, MD5 hashe, validitu vůči XML schématu či XPath dotaz. Listenery Komponenty typu Listener se starají o sběr a zobrazení výsledků měření. Od základních textových zobrazovačů odpovědí jsou tu k nalezení také různé druhy grafických výstupů. 22

3. Metodiky a přehled nástrojů Netestové položky Do této kategorie patří například komponenta určující nastavení JMeteru jako proxy serveru, použivá se při nahrávání testů. JMeter nabízí možnost distribuovaného testování, kdy je aplikace nasazena na více počítačů. Jeden počítač pak slouží jak tzv. Master a pomocí něj jsou rozesílány příkazy na podřízené počítače, tzv. Slaves. Díky zvolené platformě (Java) lze aplikaci snadno nasadit například na množství linuxových počítačů a ušetřit tak náklady za licence za jiný operační systém. Na webových stránkách produktu je k dispozici spousta dokumentace včetně návodů na základní i pokročilé scénáře, distribuovaného testování, nahrávání testů, návodů jak aplikaci rozšířit o vlastní součásti a další. K dispozici je také plná dokumentace ke všem dodávaným komponentám.

JMeter Plugins JMeter Plugins [19] je zajímavý soubor zásuvných modulů do výše zmíněného nástroje. Do hodnocení JMeteru jako takového zahrnuty nebudou, ale pro jejich přínosnost je důležité je zde uvést. Tyto moduly jsou vyvíjeny od roku 2009, Apache 2.0 licence zajišťuje možnost volného užití. Mezi velmi přínosné moduly patří například modul nazvaný Kroková skupina vláken (Stepping Thread Group), která umožňuje lépe kontrolovat zvyšování generovaných požadavků. Výbornou součástí, která je dodávána spolu s těmito moduly je PerfMon agent a listener, který zajišťuje sběr dat o využití systémových prostředků. Do výsledků testu tak lze zahrnout grafy zatížení serverů, kde je aplikace nasazena, nebo i počítačů, na kterých jsou testy spouštěny. Z hlediska grafického výstupu je tato sada modulů opravdu bohatá, doplňuje základní grafy JMeteru o mnoho užitečných výstupů, jako korelační grafy doby odpovědi nebo počtu transakcí k počtu vláken, či postupné grafy časů odezvy, propustnosti nebo počtu aktivních vláken. Všechny grafy lze kombinovat do užitečného přehledového grafu, který dovoluje promítnout vybrané grafy do jednoho. Užitečným listenerem je také AutoStop listener, který umožňuje automatické zastavení testování, pokud některá z veličin (doba odpovědi, latence, chybovost) překročí definovanou mez po určitou dobu. V kombinaci s novými skupinami vláken tak lze mnohem snáze určit maximální zátěž při daných mezích, kterou měřená aplikace zvládne obsloužit. Přidán je jeden časovač, který se týká také nastavení propustnosti. Nazývá se Throughput shaping timer a pomocí něj lze přesně modelovat, kolika vláknům bude v danou chvíli umožňěno klást dotazy vůči serveru. Pro snadné ladění měřícího scénáře přibyla komponenta zvaná Dummy sampler. Tento prvek sice žádný požadavek negeneruje, ale lze do něj přímo vepsat dotaz i odpověď. Díky němu tak lze snáze otestovat funkčnost závislých elementů (například post-processorů). Webové stránky projektu opět obsahují podrobný popis a vysvětlení k jednotlivým komponentám. 23

3. Metodiky a přehled nástrojů BlazeMeter BlazeMeter [20] je prostředí JMeteru převedené do prostředí cloudu, obohacené o další rozšíření, zejména větší možnosti zpracování výsledků. Tato služba je již placená. 3.3.2 The Grinder The Grinder [21] je framework napsaný v jazyce Java, určený ke spouštění skriptů na více počítačích. Nástroj je zdarma, dostupný pod licencí typu BSD. Díky zvolené platformě lze opět nasadit na množství linuxových strojů. Pomocí tohoto nástroje lze testovat HTTP web servery, webové služby (SOAP i REST), aplikační servery (CORBA, RMI, JMS, EJB, JDBC) a další služby a protokoly (POP3, SMTP, FTP, LDAP). Architektura je tvořena třemi základními prvky, a to výkonným procesem, procesem agenta a procesem konzole.

Obrázek 3.4: The Grinder: Konzole a agent se spuštěným skriptem Hello World. Výkonný proces je ovládán procesem agenta, vykonává skripty testů. Každý výkonný proces může mít dále spuštěných několik vláken, je řízen procesem agenta. Proces agenta spouští a ukončuje výkonné procesy a stará se o lokální kopii skriptů distribuovaných z konzole. Proces agenta může běžet i samostatně bez konzole, zadání práce se pak řídí lokálním nastavením agenta. Proces konzole koordinuje ostatní procesy, sbírá statistiky o běžících testech a distribuuje testovací skripty. Dovoluje přímou editaci skriptů, ale komfortnější bude nastavení externího 24

3. Metodiky a přehled nástrojů editoru s lepším zvýrazňováním a doplňováním syntaxe. Proces konzole poskytuje rozhraní k ovládání tohoto nástroje a lze ji spustit i bez grafického rozhraní. Testovaná verze obsahuje RESTové rozhraní, při přístupu přes webový prohlížeč tak zobrazuje základní stavové informace o agentech, spuštěných úlohách, souborech a několik dalších informací. Dále lze pomocí něj ovládat spouštění a zastavování úloh a nahrávání výsledků. Dle webu produktu je v plánu kompletní převod ovládacích prvků do webové stránky, ovládání celého procesu měření by se tak ještě více zjednodušilo. Typickým použitím je spouštění jednoho procesu agenta na každém stroji určeném pro generování zátěže. Při vypnutí konzole nebo přerušení spojení mezi výkonným procesem a konzolí dojde ve výchozím nastavení k ukončení výkonného procesu. Zabránit tomuto chování lze pomocí spouštění výkonného procesu jako služby, respektive s přepínačem daemon. Skripty pro The Grinder mohou být psány ve dvou dynamických skriptovacích jazycích. Prvním a doporučovanějším jazykem je Jython, Java implementace populárního skriptovacího jazyka Python. Druhou možností jak psát skripty je použití jazyka Clojure. Na webových stránkách nástroje je k nalezení galerie skriptů, obsahující ukázky použití pro různé účely měření. Část těchto skriptů je distribuována i v balíčku ke stažení jako sada příkladů. Nevýhodou tohoto nástroje je absence jakéholiv GUI s formuláři, ve kterých by se testy nastavily. Znalost jednoho ze skriptovacích jazyků je nutností, proto The Grinder cílí spíše na vývojáře než čisté QA testery.

3.3.3 VisualVM VisualVM [22] je nástroj vyvíjený na platformě Netbeans, určený k monitorování a profilování Java aplikací, běžících na verzi 1.4 a vyšší. K získání dat používá různých technologií (jvmstat, JMX, Attach API, Serviceability Agent), z nichž automaticky používá tu nejrychlejší a nejvhodnější za účelem způsobení co nejmenšího vlivu na výkon monitorované aplikace. Nástroj umožňuje automaticky detekovat lokálně běžící aplikace, v kombinaci s dodatečnou komponentou běžící na vzdáleném stroji nebo JMX3 spojením dokáže detekovat i vzdáleně běžící aplikace. Mezi možnosti, které tento nástroj poskytuje, patří zobrazení konfigurace aplikace a běhového prostředí, sledování výkonu aplikace a spotřebované a alokované paměti, sledování vláken, pořízení a analýza stavu vláken a haldy a mnoho dalších možností. K dispozici je také pořízení snímku stavu aplikace, uložení a pozdější offline analýza. Díky Netbeans platformě je nástroj dále rozšiřitelný, v katalogu je aktuálně 22 zásuvných modulů. VisualVM může být integrován do vývojových prostředí Eclipse či Netbeans. Program je publikován pod GPLv2 + CE licencí. Součástí balíku Java Development Kit je od verze 1.6 update 7.

3. JMX (Java Management Extensions) je technologie poskytující nástroje ke správě a monitoringu Java aplikací a zařízení.

25


Obrázek 3.5: VisualVM monitorující sám sebe.

3.4

Komerční nástroje

3.4.1 WebLOAD Nástroj zvaný WebLOAD od společnosti RadView [23] je zajímavým komerčním nástrojem primárně určeným pro testování webových aplikací. Kromě podpory HTTP/HTTPS a webových služeb (SOAP) podporuje i další protokoly typu SMTP, POP3, IMAP nebo LDAP. Mezi další podporované protokoly patří FTP, NNTP, TELNET a SSH, včetně základních protkolů TCP a UDP, které umožňují sestavit vlastní formát paketů. Navíc k těmto základním protokolům je možno tímto nástrojem testovat ERP/CRM systémy od společností SAP, Siebel, PeopleSoft, Lawson nebo JD Edwards, dále Business inteligence nástroje jako Hyperion nebo Cognos. Výjimečností je podpora pro testování multimediálního obsahu pomocí protokolů RTSP/RTP. Sestavování scénářů, které se v kontextu této aplikace nazývají Agendy se zaznamenávají pomocí vystupování WebLOADu jako proxy serveru. Takto zaznamenaný scénář lze dále upravovat, například odfiltrovat část zaznamenaného obsahu podle typu. WebLOAD poskytuje IDE, ve kterém je možno tyto testy nahrávat, upravovat, debugovat a spouštět. Výsledné testovací skripty jsou generovány do jazyka JavaScript. Během provádění těchto skriptů jsou generovány sestavy obsahující například seznamy pomalých webových stránek, navštívených adres nebo provedených transakcí. 26


Obrázek 3.6: Architektura WebLOAD [24].

Architektura je opět rozdělena na několik součástí. WebLOAD IDE je nástroj k vytváření scénářů, konzole slouží ke spouštění, plánování a kontrole testů. WebLOAD analytics slouží k analýze výsledků měření. Pod pojmem virtuální uživatel je zde myšlena reprezentace jednoho reálného uživatele měřeného systému. Poslední komponentou je generátor zátěže, kterých může být na základě parametrů testovaného systému nasazeno větší množství. Jednotlivé komponenty spolu při měření komunikují dle obrázku 3.6. Licencování a platba tohoto nástroje je dělené podle několika faktorů. Rozhodující je zejména počet virtuálních uživatelů. Příjemné může být pronájem software jen na určitou dobu. Dále lze zakoupit pluginy, licence na další konzole a podobně. Vše je podrobně popsáno na webu výrobce.

3.4.2 LoadRunner Další ze zkoumaných komerčních nástrojů je LoadRunner, aktuálně patřící společnosti HP [25]. Sada podporovaných protokolů je shodná s ostatními nástroji – CORBA, FTP, HTTP, IMAP, JMS, LDAP, MS SQL Server, ODBC, Oracle (2-Tier), POP3, RMI, SMTP, webové služby, dále podpora web 2.0 technologií jako je AJAX či Silverlight. Dle specifikací produkt dále podporuje testování vzdáleného přístupu pomocí protokolů MS Remote Desktop protokolu (RDP) nebo Citrix (ICA) [26]. Žádný z ostatních nástrojů toto nenabízí. Vytvořené skripty lze editovat pomocí Microsoft Visual Studia, výhodou může být též poskytované API, díky kterému je možno úkoly prováděné LoadRunnerem integrovat do integračních a jiných automatizovatelných podpůrných systémů. Architektura je též podobná ostatním produktům, z hlediska software je tvořena těmito částmi: řídící jednotka (Controller), vzdálený dispečer agenta (Remote Agent Dispatcher), 27

3. Metodiky a přehled nástrojů agent a virtuální uživatel (VUser). Z hlediska hardware se pak jedná hlavně o generátor zátěže (Load Generator), tedy počítač určený ke spouštění testů.

Obrázek 3.7: Architektura HP LoadRunner [27]. Agent je základním stavebním kamenem vykonávaného scénáře, spouští jednotlivé virtuální uživatele a spolu s dispečerem je nainstalován na generátoru zátěže. Dispečer dostává příkazy od řídící jednotky (Controlleru). Během spuštěného testu jsou mezi agentem a řídící jednotkou komunikovány stavy jednotlivých virtuálních uživatelů [27]. Celková cena licence pro HP LoadRunner se odvíjí od typu zakoupené sady (např. síťová sada, databáze, SOA) a od počtu virtuálních uživatelů. 3.4.3 YourKit YourKit [28] je komerční profilovací nástroj ve dvou verzích – pro svět Javy a .netu. Dle specifikací na webových stránkách výrobce má za sebou verze pro Javu delší historii a nabízí tak větší možnosti profilování. Verzi pro .net je možno integrovat do vývojového prostředí Visual Studio, Java verzi do množství jiných (např. Netbeans, Eclipse). Verze pro Javu je možno integrovat do množství JavaEE serverů, například GlassFish, JBoss, Jetty, Tomcat nebo WebSphere, .netovou variantu pak do serveru Microsoft Internet Information Services. Obě verze se ale shodnou na pokrytí webových aplikací (ASP.NET, J2EE), profilování procesoru, vláken, garbage collectoru, telemetrie výjimek, detekce deadlocků a dalších přehledů, které bychom od profilovacího nástroje očekávali, včetně možnosti připojit se již na spuštěnou aplikaci. V porovnání s volně dostupným VisualVM působí YourKit díky různým možnostem průzkumu běžícího programu i díky vzhledu svého GUI jako nástroj mnohem silnější. Každá verze nástroje je poskytována ve formě trial verze po dobu 15 dní. Zajímavostí je licencování zdarma pro účely vývoje open-source systémů a v případě verze pro .net též vlastníkům MVP certifikátu4 . 4. MVP (Most Valuable Professionals) je certifikát udělován společností Microsoft pro profesionály, kteří mají hlubokou znalost daného produktu nebo oblasti (například MVP pro C#, Visual Studio, Excel nebo firemní bezpečnost) a veřejně sdílí tyto znalosti, zkušenosti a poskytují pomoc [29].

28


Obrázek 3.8: YourKit pro Javu.

3.5

Nástroje vývojových prostředí

3.5.1 NetBeans Populární vývojové prostředí podporující především vývoj v jazyce Java umožňuje profilovat vyvíjené aplikace pomocí snadno dostupného integrovaného profileru [30]. Tento nástroj umožňuje bez větší režie procházet stavy vláken, výkon procesoru nebo využití paměti. Mezi základní nástroje patří například přehledné zobrazení běžících vláken a jejich výpočtů, analyzátor často volaných metod s ukazatelem doby setrvání v každé metodě nebo přehled alokovaných objektů, jejich počtu a typů a práce garbage collectoru. Rozhraní profileru v NetBeans je svým vzhledem velmi blízké již zmíněnému VisualVM. Na webových stránkách nástroje je k dispozici základní manuál práce s profilerem. 3.5.2 Microsoft Visual Studio Také Microsoft Visual Studio má ve své verzi Premium a Ultimate profilovací nástroj [31]. Možnosti práce v této aplikace jsou podobné již zmiňovaným nástrojům. Je nabízeno několik přístupů k profilování aplikace, a to CPU Sampling (základní metoda pro prvotní průzkum chování aplikace, výstupem je zejména využití procesoru), Instrumentation (počítá průchody funkcemi a čas trávený jejich vykonáváním), Memory allocation (přehled alokovaných ob29

3. Metodiky a přehled nástrojů jektů a jejich využití paměti, včetně příslušnosti daného objektu ke třídě objektu) a nakonec Concurrency analysis (analýza přístupu aplikace ke sdíleným zdrojům a přehled komunikace mezi součástmi aplikace). Takto zaznamenané události lze filtrovat podle času, naopak jako nevýhodu lze uvést často větší časovou náročnost na zpracování výstupů ze záznamu chování aplikace. Při delším nahrávání i na relativně výkonném počítači může trvat zobrazení zprávy až několik minut. Edice Ultimate dále nabízí vytváření zátěžových testů a testů webových aplikací. Postup vytvoření takového testu je relativně rychlý. Pomocí průvodce a zásuvného modulu do Internet Exploreru se nahraje průchod uživatele webovou stránkou, přičemž jsou automaticky detekovány přechody mezi stránkami (odkazy) nebo zadávání dat do formulářových prvků. Tento seznam akcí pak lze dále editovat a doplnit o řídící prvky jako cykly nebo podmínky. Pokud chceme jistou míru variability v zadávaných datech (například zadávaná uživatelská jména a hesla a další hodnoty do formulářů), je nutné nadefinovat zdroje dat, ze kterých jsou tyto hodnoty následně mapovány. Tímto zdrojem může být SQL databáze, CSV nebo XML soubor. U každého testu lze nastavit očekávanou adresu kam bude přesměrován, navrácený stavový kód HTTP protokolu nebo požadovanou dobu odezvy. Podle těchto ukazatelů lze pak určit úspěch nebo neúspěch daného požadavku. Čas přemýšlení lze nastavovat ke každému požadavku. Každý test může být zakončen několika validačními pravidly. Hodnotit lze například dobu odezvy, hodnotu nějakého formulářového prvku či proměnné, která byla během testu nastavena. Z testu lze vygenerovat upravitelný kód v jazyce C# nebo Visual Basic.NET. Z testů lze dále, opět pomocí průvodce, vytvořit zátěžový test. Definuje se několik položek. Rozložení času přemýšlení Časy přemýšlení nastavené v jednotlivých požadavcích testu lze buď zachovat, upravit pomocí normálního rozložení, nebo ignorovat. Dále lze přidat čas přemýšlení pro přechod mezi iteracemi testu. Vzor zátěže Použít lze buď konstatní zátěž, nebo inkrementující zátěž. Nastavuje se časová prodleva mezi zvyšováním zátěže, počáteční a maximální zatížení a inkrement zátěže. Testy a model jejich kombinace Jeden zátěžový test může obsahovat jeden nebo více testů. Pokud má být spouštěno více testů najednou, lze nastavit jejich procentuální poměr zastoupení. Pořadí spouštění jednotlivých testů lze upravit, a to buď aby bylo respektováno pořadí testů tak, jak byly zadány, nebo dle počtu virtuálních uživatelů či požadavků. Model sítě a prohlížečů Lze simulovat chování různých druhů sítí (například 3G, CDMA, LAN, ...) nebo prohlížečů a jejich verzí (Internet Explorer, Firefox, Chrome, ...) Nastavení běhu Nakonec lze upravit styl spuštění testu, a to buď na pevně zvolený čas nebo počet požadavků. 30

3. Metodiky a přehled nástrojů Velmi dobrou vlastnostní zátěžových testů je možnost upravovat počet virtuálních uživatelů během spuštěného testu, a to na základě sbíraných ukazatelů výkonu (spotřebovaná paměť, vytížení procesoru, průměrný počet transakcí, průměrný počet požadavků, chybovost testů a mnoho dalších). Na základě tohoto nastavení lze snadno určit maximální počet souběžných požadavků za nastavených podmínek pro danou konfiguraci měřeného systému. Pro generování větší zátěže na server lze test distribuovat i na jiné počítače. Tyto počítače musí být vybaveny součástí zvanou Test Agent. Microsoft na svých stránkách poskytuje manuál k základním úkonům s profilerem, jako je profilování webové či desktopové aplikace, procházení záznamů o volaných funkích, zanořeních, sběru dat a podobně. Další část dokumentace je věnovaná vývoji testů webových aplikací a následných zátěžových testů.

3.6

Další nástroje

Během vyhledávání nástrojů ke srovnání bylo nalezeno i množství jiného software, který se do srovnání nehodí, ale bylo by vhodné je zmínit. Jsou uvedeny dva nástroje, každý z jiné oblasti. 3.6.1 AppDynamics AppDynamics [32] je zástupcem z kategorie monitorovacích systémů. Ačkoliv se tento typ software týká spíše produkční fáze vývoje software, měl by být zmíněn. Poskytuje nástroje ke sledování aplikacích běžících nad Javou nebo .netem, dále sledování provozu cloudových aplikaci, prostředí NoSQL a SOA. Verze Lite je nabízena zdarma. Nasazení aplikace je velice rychlé při zanesení nepatrné režie, studie pro prostředí Java i .netu je k dispozici na webových stránkách výrobce. 3.6.2 SeleniumHQ SeleniumHQ [33] je nástroj primárně určený k automatizaci testování webových aplikací. Používá se jako plugin do webového prohlížeče Firefox. Selenium IDE je prototypovací nástroj pro tvorbu testových skriptů. Tvorba je prováděna pomocí nahrávání akcí uživatele při prohlížení webu a následného exportu a úpravy skriptu. Selenium-Grid je určen pro rozsáhlé testování na více počítačích nebo různých prostředích, lze jej proto v jisté míře použít i pro testování výkonnosti webových aplikací. Na webových stránkách produktu je obsáhlá dokumentace a návody k možným scénářům použití. Nástroj je poskytován zdarma.

3.7

Vlastní prostředky

Pokud se vývojář nebo jeho tým nerozhodne pro žádný z uvedených nebo podobných nástrojů, ale napíše si vlastní testy, ať už formou skriptů, jednoúčelových programů či vlastního frameworku, stále je to lepší varianta, než výkon netestovat vůbec. Ke slovu tak mohou přijít i spíše skriptovací jazyky jako Perl, PowerShell, Python nebo Ruby. 31


3.8

Srovnání nástrojů

Tabulky 3.1 a 3.2 ukazují souhrn vlastností každého nástroje. Uvedeny jsou pouze vlastnosti, které jsou přístupné hned po instalaci, bez dalších rošíření. Sloupec Pošta v sobě kvůli úspoře místa zahrnuje protokoly IMAP, POP3, STMP, sloupec WS pak protokoly SOAP a REST. Podpora daného protokolu je značena pomocí x v dané buňce, absence pak buňkou prázdnou. Buňkami s textem je myšlena podpora protokolu s doplňujícími informacemi. 3.8.1 Volně dostupné nástroje pro měření výkonu Srovnání nástrojů poskytovaných zdarma se zaměřením na protokoly může dle tabulky nahrávat The Grinderu, výhodou JMeteru je ale grafické rozhraní a komunita uživatelů zastřešená nadací Apache, která mnohé nedostatky doplňuje. K nalezení je například řada implementací pro testování EJB. Ve výběru mezi těmito nástroji bude hrát tedy roli hlavně umění uživatele skriptovat v jazycích Python nebo Jython, které jsou u The Grinderu nutností. Po zaučení skriptování může tato vlastnost znamenat větší výhodu, učební křivka od úplného začátku po komplexnější znalosti bude ale pravděpodobně delší než u JMeteru. 3.8.2 Komerční nástroje pro měření výkonu V oblasti komerčních nástrojů je situace obdobná. Ve specifikacích jednotlivých produktů je vždy uvedeno co největší množství protokolů k přesvědčení zákazníka. Vhodným měřítkem by proto byla spíše vlastní zkušenost dlouhodobější práce s každým z nástrojů, což ale díky jejich komerčnosti není jednoduché. U produktu WebLOAD, který je cílen především na měření výkonu webových stránek a bohatých internetových aplikací (RIA – Rich Internet Application), je zajímavá možnost testování streamovaného videa. LoadRunner, jehož protokolová základna je také velmi bohatá, překvapí možností testovat vzdálenou plochu (RDP protokol). Pokud se ve firemním prostředí nákupčí bude rozhodovat mezi těmito nástroji, svou roli jistě bude hrát také cena. RadView své ceny za WebLOAD uvádí na webu produktu, u HP je situace složitější a cena není veřejně k nalezení. Oba nástroje jsou licencovány částečně podle protokolů, dále podle počtu virtuálních uživatelů a nakonec podle způsobu nákupu software. Tabulkové srovnání pro konkrétní použití pak ukáže výhodnější balíček.

32

Bezplatné JMeter The Grinder Komerční WebLOAD LoadRunner

Bezplatné JMeter The Grinder Komerční WebLOAD LoadRunner x x

x x

x x

x x

JDBC

x x

x x

JMS

x x

x x

LDAP

x x

x x

Pošta

x x

x x

WS

x x

x

CORBA

x x

x

RMI

x x

x

EJB

x x

Extensibility SDK x

x x

TELNET

testování CRM aplikací a multimediálního obsahu testování RDP, Citrix, integrační API, podpora MS VS

projekt z Apache Foundation podpora ze strany komunity

Zajímavé vlastnosti

Tabulka 3.2: Tabulkové srovnání dalších vlastností (x značí podporu).

x x

Podpora skriptování

x x

Rozšiřitelnost

x x

SSH

Tabulka 3.1: Tabulkové srovnání podporovaných protokolů (x značí podporu).

x x

FTP

x x

HTTP


33

4 Demonstrační aplikace Pro účely praktického vyzkoušení nástrojů pro měření výkonu byla vytvořena následující webová aplikace. Tato aplikace je založena na existující komerční desktopové aplikaci napsané v Javě, která slouží nepatrně jiným účelům. Zkušenosti s tvorbou této komerční aplikace byly využity v návrhu demonstrační aplikace, která je zjednodušenou verzí svého komerčního vzoru.

4.1

Specifikace

Pro potřeby imaginární pouti bylo třeba vyvinout webovou aplikaci, která umožňuje prodej lístků na jednotlivé atrakce. Lístky mohou být tří různých typů, a to ∙

jednoduchý – jeden průchod,

∙

multi – více průchodů stejné atrakce, kdy počet průchodů je možno volit,

∙

konto – nezávislý na atrakcích, slouží jako nabitý kredit, který je opět možné zvolit.

Obrázek 4.1: Use case diagram aplikace. 34

4. Demonstrační aplikace Každý lístek je opatřen šestimístným unikátním kódem, který se ověřuje při vstupu na atrakci. Ověření na každé atrakci probíhá pomocí snímače čárového kódu na vytištěném lístku. Koncové zařízení z databáze zjistí, zda je lístek platný a podle platnosti pak zareaguje vpuštěním na atrakci, nebo upozorní návštěvníka na neplatný lístek. Z důvodu kompatibility se staršími koncovými zařízeními musí aplikace podporovat i možnost ručního vložení kódu lístku. Na kód lístku je tak kladen požadavek nesekvenčnosti, aby se předešlo tipování kódu zákazníky. Pro účely analýzy prodeje a využití prodaných lístků je nutné evidovat kdo kdy prodal jaký lístek, a také kdy a na jaké atrakci se lístek použil. Prodej je přístupný pracovníkům pouti přes webové rozhraní. Aplikace podporuje dva typy uživatelských rolí, a to běžný personál, který lístky pouze prodává, a dále manažera pouti, který může prohlížet data o prodeji, přidávát nové prodejce, měnit programy a spravovat nastavení aplikace. Komunikace koncových zařízení probíhá formou XML zpráv a HTTP stavů, jednoduché REST rozhraní. Základní interakce uživatelů se systémem jsou vidět na diagramu případů užití na obrázku 4.1. Protože si byl manažer vědom důsledků, jaké můžou výkonnostní problémy aplikace způsobit, požadoval při vývoji zkoušky o výkonnosti systému. Jako klíčové scénáře pro hodnocení výkonu aplikace byly vybrány prodej lístků, ověřování lístků a prohlížení statistik o prodeji.

4.1.1 Klíčové scénáře Prodej lístků 1

Uživatel s rolí prodejce se přihlásí do systému.

2

V menu přejde na odkaz prodej, kde se mu zobrazí seznam dostupných programů a jejich typů.

3

Vybere zákazníkem požadovaný typ a číslo programu.

4

Aplikace zobrazí náhled vygenerovaného lístku.

5

POKUD jde o typ Multi, 5.1 je navíc možné nastavit požadovaný počet opakování, 5.2 aplikace po úpravě zobrazí obnovený náhled lístku.

6

POKUD jde o typ Konto, 6.1 je navíc možné nastavit požadovanou kreditovou hodnotu, 6.2 aplikace po úpravě zobrazí obnovený náhled lístku.

7

Pokud je zákazník spokojen, může prodejce přes tlačítko Prodat provést prodej lístku.

Po prodeji lístku by mělo dojít k jeho vytištění. Tiskárna je ale externí systém a v měření výkonu zahrnuta není. Demonstrační aplikace pouze zobrazuje zprávu o úspěšném prodeji. 35

4. Demonstrační aplikace Ověřování lístků 1

Zařízení vyšle k aplikaci požadavek s ID atrakce, programu a kódu lístku.

2

Aplikace se pokusí najít lístek v databázi.

3

POKUD jde o Jednoduchý nebo Multi lístek, 3.1 dojde k ověření platnosti lístku (volný počet opakování) a shody čísla požadovaného programu a programu, na který byl program vydán.

4

POKUD jde o typ Konto, 4.1 dojde k ověření dostatku kreditu na tomto lístku.

5

POKUD lístek existuje, není prošlý a kontroly dostatku kreditu nebo počtu opakování jsou v pořádku, 5.1 aplikace odpoví kladně a zařízení může zákazníka vpustit.

6

JINAK 6.1 aplikace odpoví záporně a zákazník je upozorněn na neplatnost svého požadavku.

Zobrazení statistik o prodeji Statistiky prodeje jsou k dispozici na zvláštní stránce. Pro demonstrační účely byly vytvořeny 4 grafy, u kterých je měřena a laděna rychlost jejich zobrazení. U každé statistiky lze volit datumový rozsah, pro kterou má být spočítána. Implementovanými statistikami jsou: ∙

poměr zakoupených programů,

∙

poměr zakoupených typů lístků,

∙

poměr používaných programů pro lístky typu účet,

∙

poměr využitých/nevyužitých programů Jednoduchého typu.

4.2

Implementace, použité technologie a nástroje

∙

MS C#.NET ve verzi 4.5 (C# 5).

∙

MS ASP.NET MVC Razor framework verze 4. Vývoj v tomto frameworku umožňuje snadno oddělit funkcionalitu, model aplikace a pohledy. Pohledy byly tvořeny pomocí Razor syntaxe představené v MVC verze 3.

∙

HTML, CSS a další standardní technologie používané při vývoji webových aplikací.

∙

MS Entity Framework ve verzi 5. Tato komponenta zajišťuje mapování objektů do relační databáze.

∙

MS IIS Express verze 8. Tato aplikace slouží jako webový server.

∙

MS SQL Server ve verzi 2012 Enterprise SP1 64bit.

∙

MS Visual Studio ve verzi 2012 Ultimate Update 1. 36

4. Demonstrační aplikace Mimo zmíněné technologie bylo pro správu uživatelů použito rozhraní Forms Authentication APS.NET, a dále DI/IoC kontejner StructureMap. Aplikace je internacializována, přeložena byla do českého a anglického jazyka. Tyto vlastnosti tak zaručují použití technologií a přístupů, které jsou běžné u rozsáhlých projektů, což přispívá k profesionálnějšímu vzhledu kódu, uživatelského rozhraní, i komplexitě výsledného produktu. Vývoj probíhal zejména pomocí Visual Studia a Code-First přístupu Etity Frameworku. Vytvořeny tak byly základní třídy modelu, které entity framework pomocí nadefinovaného mapování automaticky vytvořil v databázi. Výsledný diagram tříd je vidět na obrázku 4.2.

4.2.1 Diagram tříd Atrakce pouti jsou reprezentovány třídou Program. Každá atrakce má své ID, dále se eviduje cena jednoho vstupu, název atrakce a popis. Prodej lístků na jednotlivé atrakce může být dočasně zakázán.

Obrázek 4.2: Diagram tříd popisující model aplikace. 37

4. Demonstrační aplikace Koncová zařízení na atrakcích reprezentuje třída Device, uchovává si v sobě pouze název atrakce. Prodaný lístek je evidován třídou Ticket. Typ lístku určuje výčtový typ TicketType, reprezentující specifikované druhy lístků. O lístku je uchováván jeho kód, datum nákupu a expirace, kredit v případě typu Konto, počet opakování v ostatních případech. Nákupní cena je evidována pro všechny typy. Dle požadavku jsou informace zaznamenávány do dvou logů, a to log prodávaných lístků a log používaných lístků. Prodávané lístky jsou uchovávány pomocí tříd AccountingLog, obsahující časovou známku prodeje a některé účetní informace (cena nákupu, kredit, počet opakování, navázaný lístek, prodejce). Záznam o použití lístku je reprezentován třídou DeviceLog, která opět uchovává časovou známku, dále pak ID zařízení, které použití lístku provedlo, cenu svázaného programu v daném okamžiku (důležité zejména v případě lístku typu Konto), lístek a program na který se záznam váže. Oba účetní logy mohou reprezentovat události specifikované v příslušných navázaných výčtových typech DeviceLogEventType a AccountingLogEventType. Osoby používající systém jsou evidovány pomocí tříd typu SalesPerson, které udržují informace o jméně a příjmení, osobním čísle a loginu uživatele. Hesla jsou spravována interně pomocí výše zmíněné komponenty Forms Authentication. Role dané osoby je reprezentována výčtovým typem PersonRole. Každé osobě lze podobně jako v případě programu dočasně pozastavit platnost. Objekty typu Setting reprezentují nastavení aplikace. V demo aplikaci se toto nastavení týká textů na prodaném lístku. V diagramu je odfiltrováno zobrazení některých pomocných vlastností, jako pomocné cizí klíče pro Entity Framework, vlastnosti určené pro použití v pohledech jako pomocné textové hodnoty a podobně. 4.2.2 Projekty tvořící aplikaci SalesTerminal.DatabaseFiller Tento projekt obsahuje konzolovou aplikaci, která slouží k naplnění databáze testovacími daty (prodej a používání lístků). Nakonfigurovat lze počáteční datum vkládání, počet dnů běhu aplikace, které tento program nasimuluje, a násobek generovaných lístků. Každý den je vloženo několik lístků, další jsou použity. Typy a čísla programů jsou voleny náhodně a vychází z dat vložených při generování databáze. Při vzorové konfiguraci násobku 13 databáze po jednom nasimulovaném roce provozu obsahuje asi 160 tisíc prodaných lístků a 900 tisíc záznamů o použití zařízením. Díky této aplikaci lze snadno a relativně rychle vložit do databáze větší množství dat a následně tak sledovat vliv plnější databáze na výkon systému. SalesTerminal.Model Obsahem tohoto projektu je model aplikace – diagram tříd a třídy zmíněné výše. Třídy a jejich vlastnosti jsou anotovány pro použití v entity frameworku a pohledech MVC. 38

4. Demonstrační aplikace SalesTerminal.WebApp V tomto projektu je hlavní aplikace v ASP.NET MVC frameworku. Obsahem projektu jsou tedy controllery, pohledy, modely pohledů a další obsah a třídy, které jsou vidět ve webové aplikaci. Aplikace je nastavena tak, aby zresetovala databázi při každé změně modelu. Tohoto chování lze proto využít při prvním nasazení aplikace, kdy je databáze automaticky vytvořena. Vloženy jsou demonstrační programy a testovací uživatelé. Obsah je podrobněji popsán v příloze B. Na obrázku 4.3 je vidět ukázka zobrazení aplikace v prohlížeči. Zobrazovanou stránkou je demonstrační výpočet poměru zakoupených lístků dle programu. Tyto grafové výstupy byly použity jako výstup výpočtů u kterých lze ladit výkonnost. Každá vygenerovaná stránka obsahuje v patičce údaj o čase výpočtu na straně serveru (cesta do prohlížeče a doba potřebná pro zobrazení stránky není započítána). Více je zmíněno v následující kapitole.

Obrázek 4.3: Ukázka demonstrační aplikace.

SalesTerminal.WebApp.Resources Tento projekt je určen pouze pro texty zobrazované v demonstrační aplikaci. Přítomen je jeden balík textů a jeho česká jazyková mutace. 39

4. Demonstrační aplikace SalesTerminal.WebApp.Tests V tomto projektu jsou testy vytvořené ve Visual Studiu určené k měření výkonu výše zmíněné aplikace (projektu SalesTerminal.WebApp). Scénáře a testy jsou více popsány v následující kapitole. SalesTerminal.WebApp.Tests.Plugins Tento projekt obsahuje vlastní třídu Randomizer potřebnou pro generování náhodných hodnot pro test SalesPerson.

40

5 Aplikace nástrojů pro měření a ladění výkonu Tato kapitola popisuje na začátku hardware, na kterém bylo chování aplikace měřeno. Hlavním tématem je ale popis použitých testovacích scénářů a praktické srovnání použitých nástrojů pro měření výkonu. Podrobněji jsou popsány použité komponenty vybraného nástroje a naměřené výsledky. Dále jsou pak popsány provedené kroky směřující ke zlepšení výkonu demonstrační aplikace a srovnání výsledků. V závěru kapitoly je využito i nástrojů Visual Studia pro odhalení potenciálního maxima na hardware představeném na začátku kapitoly.

5.1

Testovací prostředí

Při měření a ladění výkonu demo aplikace byl použit hardware popsaný v následujících tabulkách 5.1 a 5.2. Původní záměr byl nasadit aplikaci na virtuální Windows Server 2012 s plnohodnotným IIS 8 a MS SQL serverem, hostovaný na počítači viz tabulka 5.1. Jak se ale později při měření výkonu ukázalo, režie virtuálního prostředí byla větší, než potenciální výhody plnohodnotného webového serveru. Z tohoto důvodu byl nakonec využit server IIS Express instalovaný spolu s Visual Studiem 2012. Typ Procesor RAM OS disk Data disk OS

Desktop AMD Phenom II X4 B55, 3.2 GHz 8 GB 1600 MHz 128 GB SSD OCZ Vertex 4 Seagate 7200.12 1 TB, 32 MB cache, SATA 2 Windows 7 SP 1 64bit

Tabulka 5.1: Počítač na kterém byla aplikace nasazena. Operační systém byl nainstalován na disku označeném jako OS disk, na disku označeném jako data disk byly umístěny soubory databáze aplikace připojované do SQL serveru. Stránkovací soubor o velikosti 8 GB byl též umístěn na data disku, díky velikosti paměti ale nebyl zapotřebí. Během spuštěného testu bylo na počítači s aplikací přepnuto preferování služeb běžících na pozadí před spuštěnými aplikacemi. Ostatní nastavení bylo ponecháno ve výchozím stavu, tj. soubory aplikace a kompilované pohledy byly na rychlém SSD disku. Typ Procesor RAM Disk OS Java

Notebook Inter Core i5 M 520, 2,4 GHz Hyper Threading 4 GB 1066 MHz 160 GB 5400 ot., 8 MB cache, SATA 2 Windows 7 SP 1 64bit Oracle 7u9 64bit

Tabulka 5.2: Notebook určený pro spouštění testů. 41

5. Aplikace nástrojů pro měření a ladění výkonu Aby došlo k odstranění vlivu měřícího nástroje na výkon měřené aplikace, byly testy spouštěny na notebooku viz tabulka 5.2. Počet spuštěných programů na počítači s aplikací byl omezen na minimum, aby došlo během testování a měření k odstranění všech nežádoucích vlivů. Počítače byly ve stejném síťovém segmentu, propojeny přes síťový kabel a switch o rychlosti 100 Mbit/s.

5.2

Praktické srovnání JMeteru a nástrojů Visual Studia

Visual studio do předchozího srovnání zahrnuto není, neboť se nejedná čistě o nástroj pro měření výkonu. V zásadě podporuje testování a měření čehokoliv, k čemu lze přistupovat přes zvolený jazyk testu (C#, VB.NET). Součásti Ultimate edice pro testování výkonu webových aplikací jsou zase zaměřené pouze na jednu oblast. 5.2.1 Nahrávání testu Oba nástroje dovolují nahrávat testy přímo pomocí průchodu scénářem v prohlížeči. V případě Visual Studia se tato akce spustí klikem na jedno tlačítko, JMeter je třeba nastavit (nicméně na webových stránkách projektu je k tomuto úkolu několika stránkové pdf s podrobně popsaným postupem). Visual Studio automaticky detekuje jaké akce (procházení stránek) a jaké hodnoty formulářových prvků má do scénáře zahrnout, v případě JMeteru je situace složitější – v nastavení proxy serveru a nahrávacícho controlleru je třeba upravit filtr obsahu, jinak dojde k nahrání všeho, co se při průchodu scénářem od serveru požaduje (kaskádové styly, obrázky, skripty). V některých případech toto chování může být výhodnější, v případě demo aplikace to tak ale nebylo. Výhodou Visual Studia je zaznamenávání doby přemýšlení mezi jednotlivými požadavky. 5.2.2 Úprava a možnosti testu Při srovnání komponent, které nabízejí tyto aplikace je výhoda více na straně JMeteru. Visual Studio se omezuje v podstatě pouze na podmínku a cyklus, což je v porovnání s množstvím controllerů v JMeteru nedostatečné. Práce s nástrojem od Microsoftu je tak nepatrně odlišná – pro stejný scénář je nutné buď nadefinovat více testů, nebo tok testu kontrolovat množstvím podmínek. Porovnání uživatelské přívětivosti při editaci testů je JMeter také vítězem, i když i v jeho případě jsou přítomny jisté nedostatky. Při chycení položky testu myší a přenášení k jiné položce je v případě JMeteru nabídnuto kam se má umístit (před, po, dovnitř). Visual Studio tak přívětivé není a přemístit jeden požadavek do nějaké podmínky v podstatě znamená jej celý znovu vytvořit. Na druhou stranu, testy ve Visual Studiu mohou působit přehledněji díky možnosti zobrazení všech parametrů a datových zdrojů přímo ve stromu požadavků. Zmíněným nedostatkem JMeteru je chování při vyjmutí obsahu jednoho controlleru a vložení do druhého v případě víceúrovňového obsahu (controllery, post-processory a podobně). V tomto případě totiž sice dojde ke správnému vložení všech položek, ale také se znovu vloží položky z dalších a dalších úrovní. 42

5. Aplikace nástrojů pro měření a ladění výkonu Oba nástroje ukládají konfiguraci testů ve formátu XML a tak se lze v nejhorších připadech u každého nástroje uchýlit přímo k editace zdrojového dokumentu. XML formát přínáší také možnost generovat testy vhodným externím nástrojem. Výhodou Visual Studia může být přímá simulace více prohlížečů, rychlosti sítě a jednodušší správa spouštěných testů. JMeter na druhou stranu nesimuluje chování prohlížeče, což v případě webových stránek znamená, že pokud explicitně do scénáře nezadáme stahování dalších souborů jako jsou obrázky či styly, JMeter bude stahovat jen hlavní HTML dokument. Pokud nám toto chování nevyhovuje, stahování těchto souborů lze vynutit například díky možnosti nahrávání scénáře, nebo vytvořením komponenty, která bude stahovat dokumenty z odkazů na styly, skripty nebo obrázky. 5.2.3 Výstupy z měření a možnosti jejich zpracování JMeter nabízí ve výchozí konfiguraci množství listenerů, které dále obohacují JMeter Plugins. Graf časů odpovědí, tabulkový výpis a agregační tabulky ale pro základní dojem z výkonu aplikace naprosto dostačují. Pro ostatní potřeby zpracování výsledků je možné vše ukládat do souborů. Tyto soubory lze později buď načíst zpět do JMeteru, nebo zpracovat v nějakém externím nástroji například typu tabulkový editor. V případě Visual Studia se výsledky ukládají do databáze MS SQL. Samotné Visual Studio nabízí dostatečné možnosti pro zpracování. Pokud by reprezentace tímto nástrojem nestačila, síla a potenciál SQL Serveru se v tomto případě dá využít mnoha směry (MS Reporting Services, vlastní dotazy nad daty nebo export do jiných nástrojů). 5.2.4 Výsledné hodnocení a výběr primárního nástroje Nabídka nástrojů Visual Studia je bohatá a zejména v Ultimate verzi nabízí opravdu ultimátní balík pro každé zákoutí vývoje aplikací. Všechny možnosti tohoto nástroje ale využije jen málo který vývojář, zejména při maloobchodní ceně 350 000 Kč. JMeter dokáže možnosti Visual Studia v testování výkonu webových aplikací zastoupit. V případě nedostatku funkcionality nebo potřeby specifické komponenty ji lze díky veřejnému rozhraní samostatně vyvinout. Pro praktickou část této práce byl zvolen jako primární nástroj pro měření výkonu JMeter. Důvodem je volná dostupnost a také ilustrativní charakter scénářů definovaných v tomto nástroji. Jako komerční alternativa bylo použito Visual Studio 2012 Ultimate. Pro praktické srovnání byly obdobné testy navrženy za pomocí obou nástrojů. Scénáře z Apache JMeteru jsou popsané v následující kapitole, snímky obrazovek obdobných testů z Visual Studia jsou v příloze C.

5.3

Měřená funkcionalita a položky scénáře

Pro hodnocení výkonu byly vybrány části aplikace zvolené v kapitole 4.1.1. Na obrázku 5.1 je vidět rozložení scénáře pro měření výkonu v Apache JMeter. Popis použitých komponent a jejich nastavení je uveden v následujícím přehledu. 43

5. Aplikace nástrojů pro měření a ladění výkonu

Obrázek 5.1: Měření klíčových případů užití modelované v nástroji JMeter.

∙

HTTP Header Manager Tato komponenta obsahuje jediné nastavení, které se přidává do hlavičky každého HTTP požadavku Accept-Language: cs-CZ, což vynucuje generování stránek pro JMeter v českém jazyce.

∙

HTTP Request Defaults Dvě položky tohoto typu umožňují snadno přepínat cíl testu, a to buď na zmíněném virtuálním serveru s Windows 2012, nebo na aplikaci nasazenou na IIS Express. V položkách je nastavena IP adresa (verze 4) a port, které se dědí jako výchozí hodnoty do dalších komponent. Zašedlá komponenta je aktuálně vypnuta.

∙

SalesPeople Tato skupina vláken testuje chování scénáře prodeje lístků. Použita byla vždy Ultimate Thread Group z balíku JMeter Plugins, neboť dovoluje snadno nastavit délku doby měření. 44

5. Aplikace nástrojů pro měření a ladění výkonu ∙

Users CSV Položka typu CSV Data Set Config importuje csv soubor s uživatelskými jmény a hesly, které jsou používány pro přihlašování do aplikace. Každý řádek reprezentuje jednoho uživatele, který je použit pro jedno testovací vlákno.

∙

HTTP Cookie Manager Tato komponenta neobsahuje žádné nastavení, ale je důležitá pro správu cookies. Pokud bychom chtěli každou iteraci zrušit předchozí nastavení uložené v cookies, můžeme to udělat v této komponentě.

∙

Login (only once) Tato komponenta typu Only Once Controller zajišťuje, že její podčásti jsou spuštěny pouze při prvním průchodu testem. Toho je využito pro simulaci přihlášení každého uživatele.

∙

Login page a XPath Extractor Login page slouží pro odeslání HTTP GET požadavku na přihlašovací stránku. Pro demonstraci parsování výsledků dotazu MVC aplikace posílá jako výzvu zabezpečovací token, který musí být pro validitu přihlášení odeslán spolu s přihlašovacími údaji. Pro účel zjištění této hodnoty byl použit Post Processor typu XPath Extractor, který pomocí XPath dotazu uloží hodnotu tohoto pole do proměnné verificationToken. Nastavení této komponenty je vidět na obrázku 3.3.

∙

Login Tato komponenta je také HTTP požadavek, v tomto případě POST. Kromě přihlašovacího jména a hesla načteného z CSV je odesílána také proměnná verificationToken zjištěná v předchozím kroku.

∙

Sale Sale odešle podobně jako Login page pouze HTTP GET požadavek na nastavenou relativní adresu, v tomto případě /Sale.

∙

Available programs Součást typu Regular Expression Extractor slouží k parsování dostupných programů. Hodnota je uložena do proměnné availablePrograms. Je využito také vlastnosti této komponenty umožňující náhodný výběr z nalezených hodnot, takže se při každém průchodu náhodně vybere jeden program.

∙

Interleave controller Tento controller slouží k výběru jedné z možností – výběr typu lístku. Při každém průchodu se provede pouze jedna operace (Single, Multi nebo Account) a její podoperace.

∙

Repetition Count a Credit Random Variable komponenty, slouží k náhodnému vygenerování hodnoty pro kredit nebo počet opakování. Obě jsou uloženy do proměnné příslušného názvu.

∙

Single Ticket, Multi Ticket, Account Ticket Tyto komponenty jsou typu HTTP Request. Single a Multi využívají proměnné s náhodně vybraným programem.

45

5. Aplikace nástrojů pro měření a ladění výkonu ∙

Repetition count setting a Amount setting HTTP POST požadavky pro nastavení hodnoty počtu opakování nebo kreditu.

∙

Sell HTTP GET požadavek potvrzující nákup lístku. Může být stejný pro všechny typy lístku, proto je uveden až nakonec.

∙

Gaussian Random Timer Časovače, které zanášejí do testovaného scénáře náhodnou míru zpoždění. Jsou tvořeny konstantní dobou zpoždění a odchylkou.

Komponenty obsažené ve scénářích Manager i Devices jsou již podobné komponentám zmíněný ve scénáři SalesPeople. Rozdílná je pouze položka Use ticket, která formou HTTP POST požadavku neposílá hodnoty proměnných, ale přímo XML dokument. Simuluje tak chování REST požadavku. Předchází jí ještě jeden HTTP Header Manager, který v tomto případě specifikuje typ dokumentu: Content-Type: application/xml. Scénář uzavírá několik listenerů, které zobrazují různým způsobem nasbírané hodnoty. Všechny tyto listenery patří do základní sady komponent dodávaných s JMeterem. ∙

Graph Results Tento listener zobrazuje formou grafu vývoj rychlosti odezvy na požadavky. Zakresleny jsou hodnoty průměru, mediánu, odchylky a propustnosti dotazů.

∙

View Results in Tree Listener zobrazující požadavky a jejich odpovědi textovou formou. Vhodné pro ladění testů.

∙

Summary Report Listener agregující všechny požadavky podle jejich názvu. Zobrazuje pole počet vzorků daného požadavku, průměrná, maximální a minimální doba odezvy, standardní odchylka, procentuální poměr chybových vzorků, propustnost, počet KB za sekundu a průměrný počet bajtů.

∙

Aggregate Report Obsahuje podobné informace jako předchozí listener, navíc má hodnotu 90% percentilu.

5.3.1 Provádění měření Samotné měření poté probíhalo nad databází s jedním rokem simulovaného provozu. Z této databáze byl pomocí SQL dotazu GetTicketNumbers.sql (je obsažen v příloze) exportován seznam platných kódů lístků používaný při testování. Obsah databáze byl zálohovaný a před každým novým spuštěním měření navrácen do původního stavu. Zajištěno tak bylo odstranění vlivu datových změn do měření kódu aplikace. Původní domněnka, že bude zapotřebí alespoň dvou počítačů pro reálné vytížení takto nasazené aplikace, byla brzy vyvrácena. Jak se ukázalo po spuštění prvních zátěžových testů, jasným úzkým místem byl v tomto případě procesor, přičemž vytížení procesoru notebooku nepřesáhlo 10 procent a pohybovalo se spíše mezi 3-4 procenty. 46

5. Aplikace nástrojů pro měření a ladění výkonu 5.3.2 Výsledky měření před úpravami První měření okamžitě ukázalo chybu v implementaci algoritmu pro vydávání unikátního čísla lístku. Aplikace přidělovala buď více prodejcům stejné číslo, nebo jednomu prodejci stejné číslo i poté, co lístek s tímto číslem byl již vydán. Lístky musí být dle specifikace opatřeny unikátním číslem, v databázi je toto ošetřeno pomocí unikátního omezení daného sloupce. Pokusy o vkládání lístku s již existujícím číslem tím pádem generovaly chybové hlášky. K dispozici byly tedy vcelku rychle první výsledky, v tomto případě spíše funkčního testu. Pokud byla aplikace procházena ručně, k ničemu takovému nedocházelo, ale desítky virtuálních uživatelů generující požadavky současně již dostaly aplikaci do problémů. Z tohoto důvodu bylo nutné před dalším pokračováním nejdříve generování čísel odladit po funkční stránce. Zátěž v podobě počtu souběžných uživatelů a nastavení časovačů byla postupně navyšována, výsledné nastavení je následující. Pro první časovač ve scénáři SalesPeople byla použita konstantní hodnota 2 sekundy s odchylkou 200 ms. Tento časovač byl aplikovaný na všechny požadavky v této kategorii. Na druhý časovač v tomto scénáři bylo aplikováno ještě zpoždění 3 sekundy s odchylkou 300 ms. Tyto hodnoty udávají průměrnou rychlost průchodu aplikací reálnou osobou. Počet souběžných vláken byl nastaven na 80, doba náběhu byla 30 sekund a sestupu 10 sekund. Doba provozu pod plným zatížením byla 260 sekund. Ve scénáři Devices byl časovač nastaven na jednu sekundu s odchylkou 100 ms. Počet souběžných vláken byl nastaven na 100. V průměru tak přišlo k aplikaci z tohoto scénáře 100 požadavků za sekundu. Časování vláken bylo stejné jako v předchozím případě. Ke scénáři byly později přidány ještě listenery a agent pro sledování výkonu systému ze sady JMeter Plugins, ze kterých pochází i graf na obrázku 5.2. Výhodou tohoto řešení je možnost spojení více výstupů do jednoho grafu. Další údaje z tohoto měření obsahuje tabulka 5.7. Chybovost testu1 byla 0 %. Jak je vidět z hodnot i grafu, doba odezvy byla v průměru pod 100 ms, což je uspokojivé (i když opomeneme výsledek ze scénáře Devices, který průměr hodně ovlivňuje). Vytížení procesoru bylo ale v průměru větší než 60 %, což by při nevyrovnaném zatížení, jaké bylo nastaveno v tomto testu, již mohlo způsobovat mnohem větší odchylky v dobách odpovědi. Výhodou scénářů napsaných v JMeteru je jejich snadná transformace na funkční testy, zátěžové testy či testy škálovatelnosti. Vždy se jedná pouze o změnu zátěže, kterou JMeter generuje, tedy počet vláken ve skupinách vláken. Dalším provedeným pokusem tedy bylo zvýšení zátěže na 1000 zařízení a 400 prodejců, přičemž k tomuto bylo ještě omezeno použití jader procesoru na dvě pro aplikaci IIS Express a jedno pro SQL Server. Ani v tomto případě se chybovost nezměnila. Co se však změnilo byla doba odezvy, která se ustálila na hodnotách okolo 16 sekund. Dalším zvyšováním zátěže by chování aplikace bylo obdobné, stropem pro tyto akce by pak bylo nastavení maximální doby požadavku, což by začalo generovat chyby pro vypršení časového limitu. Toto chování lze nastavit jak v JMeteru, tak omezit v konfiguraci IIS Express.

1. Aby byly výsledky měření výkonu relevantní, je třeba při měření výkonu dosáhnout co nejnižší funkční chybovosti.

47


Obrázek 5.2: Výstup z měření prodeje a používání lístků. Poznámka pro černobílý tisk: horní linka je doba odezvy akce Sell, pod ní je čas pro výpočet stránky měřený aplikací, druhá linka od spodu je procentuální vytížení procesoru na měřeném počítači a spodní linka je doba odezvy akce Use ticket. Název testu Use ticket Login page Login Sale Single Ticket Multi Ticket Account ticket Repetition count setting Amount setting Sell

Poč. vzorků 26458 80 80 2117 720 713 674 709 662 2068

Průměr (ms) 20 8 180 81 82 86 83 82 80 85

Std. odch. (ms) 39 8 25 31 27 32 27 30 26 42

90% perc. (ms) 41 15 207 109 107 114 112 108 104 112

Celkem

34281

35

46

81

Tabulka 5.3: Další údaje z měření na obrázku 5.2. Standardní odchylka vyjadřuje míru odlišnosti hodnot od svého průměru, 90 % percentil ukazuje dobu odezvy, kterou splnilo 90 % požadavků.

48

5. Aplikace nástrojů pro měření a ladění výkonu Měření scénáře Manager bylo prováděno samostatně, za účelem odladit rychlost odezvy při generování statistik. První implementace byla extrémně pomalá (řádově desítky sekund při zobrazení statistik pro celý rok), úpravou algoritmů bylo dosaženo mnohem lepších výsledků.

5.4

Hodnocení naměřených vlastností

Za účelem zjištění (v tomto případě spíše potvrzení) úzkého místa zvolené implementace systému bylo využito nástroje s názvem Sledování výkonu, konkrétně systémová sestava System Performance. Tento nástroj je součástí operačních systémů Microsoft Windows. Výkon byl sledován při dvojnásobném nastavení počtu uživatelů oproti původnímu scénáři, doba měření byla ponechána ve výchozím nastavení jedné minuty. Měření výkonu pomocí tohoto nástroje bylo spuštěno až po dosažení plného zátížení 360 vlákny. Proces iisexpress.exe sqlserv.exe

CPU (% využití) 85,5 3,2

RAM (pracovní sada) 190 MB 212 MB

Tabulka 5.4: Nejvíce vytěžující procesy. Jak je vidět v tabulce 5.4 i v grafu na obrázku 5.2 z předchozí podkapitoly, využití procesoru je téměř na svém maximu. Pokud se podíváme na vytížení ostatních součástí systému, výkon procesoru je zřejmé úzké místo. V případě disků byl nejvytížěnějším disk se soubory databáze (střední doba nečinnosti 98 %) s průměrným počtem zápisů byl 117 za sekundu a střední délkou fronty 0,055. Tyto hodnoty značí, že zde jsou velké výkonové rezervy. Co se týče sítě, tak ani zde nebyla výkonnostní hranice zdaleka dosažena. Přes protokol TCP přicházelo i odcházelo z měřeného počítače v průměru 157 požadavků za sekundu příchozí rychlostí 63 kB/s a odchozí 180 kB/s. Se znalostí úzkého místa bylo měření spouštěno znovu, tentokrát i s pomocí profilovacího nástroje Visual Studia. Během měření byla vypnuta součást IntelliTrace2 , která značně zvyšuje režii aplikace. Z důvodu větší velikosti jsou snímky těchto výsledků zařazeny v příloze C. Z výsledků profilovacího nástroje vyplynulo jako nejvytíženější místo v aplikaci vykreslování horního menu. Z důvodu různých rolí uživatelů (v této aplikaci prodejce a manažer) bylo při každém vykreslení menu zjišťováno, zda právě přihlášený uživatel nese aplikační roli manažera. Toto dotazování mělo značný vliv na výkon (56 % ze všech výpočtů).

5.5

Aplikované techniky pro zvýšení výkonu

Pro zlepšení výkonu popsaném v předchozí části bylo nejprve použito kešování rolí v cookies prohlížeče. Jak se ale ukázalo, kešování cookies mělo na výkon aplikace téměř nulový vliv, neboť funkce musela být neustále volána i v tomto případě. Jako druhá taktika bylo zvoleno napsání vlastní metody pro zjištění uživatelské role. Tento krok již přinesl značné zlepšení výkonu, které ale bylo dále vylepšeno použitím kešování. 2. IntelliTrace slouží pro detailní záznam každého kroku aplikace.

49

5. Aplikace nástrojů pro měření a ladění výkonu 5.5.1 Použití kešování Protože menu aplikace je při každém vykreslení stejné a závisí jen na roli přihlášeného uživatele, není nutné jej generovat znovu při každém požadavku. Pro ověření zlepšení bylo nejdříve implementováno kešování přimo ve sdíleném pohledu _Layout.cshtml, což ale porušovalo čistý návrh pomocí MVC. Z důvodu aplikovatelnosti tohoto řešení na více místech bylo použito vlastního atributu ContentOutputCache, inspirovaného blogovým příspěvkem [34]. Kešování výsledků bylo navrženo tak, aby umožňovalo specifikovat proměnné, na kterých výsledek závísí. V tomto případě to byla jazyková mutace webu a přihlašovací jméno aktuálního uživatele. Závislost by mohla být dále vylepšena například o kešování menu pouze podle role. Třída tohoto atributu se nachází v projektu SalesTerminal.WebApp ve složce CustomAttributes (soubor ContentOutputCacheAttribute.cs). Použití atributu je vidět ve zdrojovém kódu 5.1. Parametr CacheDuration určuje dobu kešování v podobě absolutní doby platnosti v sekundách (použitím nakešované hodnoty se platnost neprodlužuje), parametr VaryByParams specifikuje seznam proměnných, podle kterých se určuje platnost hodnoty v mezipaměti (userName značí uživatelské jméno, lang zvolenou jazykovou mutaci webu). Atribut ChildActionOnly slouží jako ochrana volání této akce, dovoluje ji volat pouze nepřímo z jiného pohledu. [ ChildActionOnly ] [ ContentOutputCache ( CacheDuration = 6 0 0 , VaryByParams = new S t r i n g [ ] { " userName " , " lang " } ) ] public P a r t i a l V i e w R e s u l t Menu ( ) { r e t u r n P a r t i a l V i e w ( "_Menu" ) ; } Zdrojový kód 5.1: Použití atributu pro kešování. Výsledkem této úpravy byla značná úspora výpočetního výkonu (vytížení procesoru kleslo ze 60 % na 40 %) a zrychlení odezvy aplikace (z průměrných cca 80 ms na cca 30 ms). Zlepšení ale nemělo žádný vliv na rychlost scénáře Devices, neboť tam se tato akce nepoužívá. Kešování pomocí tohoto atributu bylo dále aplikováno na výsledky v menu Statistika uživatele Manager. V tomto případě je závislé na zvoleném počátečním a koncovém datu. V případě, že v rámci doby platnosti takto nakešovaného grafu bude požádáno o graf omezený stejnými daty, nemusí se znovu přepočítávat, ale je načten z mezipaměti.

5.5.2 Změna algoritmu Optimalizace výpočtu demo statistik proběhla ve třech krocích, rozložení výsledků dotazování všemi způsoby je vidět na grafu na obrázku 5.3. Všechny tři příklady jsou k nalezení po přihlášení jako Manažer v menu Manažer (demo). Měření probíhalo po dobu pěti minut několikanásobným opakováním každého dotazu. 50


Obrázek 5.3: Rozložení časů odpovědi pro různé výpočty zvolené statistiky. Poznámka pro černobílý tisk: LINQ Memory jsou hodnoty nejvíce vpravo, Native SQL jsou hodnoty nejvíce vlevo, částečně sdílejí sloupec 100 ms s LINQ SQL. První implementace (v grafu hodnoty LINQ3 Memory) byla velmi pomalá při dotazování většího datového rozsahu. Důvodem je nevyužití výkonu výpočtů prováděných přímo v SQL Serveru a také načítání všech informací o každém objektu. LINQ dotaz fungoval způsobem kompletního načtení všech objektů z datového rozsahu z databáze pomocí Entity Frameworku a následný výpočet až v operační paměti. Tento způsob výpočtu byl nejen ze všech nejpomalejší, ale také paměťově nejnáročnější. Pro jeden rok simulačních dat trval výpočet jednoho grafu okolo 4 sekund. Paměťová náročnost všech takto načtených objektů byla okolo 60 MB. Druhým krokem bylo zlepšení LINQ dotazu tak, aby z databáze načítal až vypočtené hodnoty. Optimalizace spočívala ve výměně a drobné úpravě dvou kroků LINQ dotazu. Výsledné hodnoty jsou již mnohem uspokojivější, pro stejná data trval výpočet 100-200 ms namísto původních 4 sekund. Obě verze jsou vidět ve zdrojovém kódu 5.2. / / vypocet v pameti var pointsComputeInMemory = _db . T i c k e t . Where ( t => t . PurchaseDate >= model . S t a r t D a t e && t . PurchaseDate <= model . EndDate && t . TicketType ! = TicketType . Account ) . GroupBy ( g => g . ProgramID ) . ToList ( ) . T o D i c t i o n a r y ( key => key . F i r s t O r D e f a u l t ( ) . Program . Name, value => ( double ) value . Count ( ) ) ;

3. Language-Integrated Query (LINQ) je sada rozšiřující dotazovací schopnosti syntaxe jazyka C# a VB.NET o další možnosti práce s daty v objektové, XML nebo SQL podobě [35].

51

5. Aplikace nástrojů pro měření a ladění výkonu / / nacitani az vyslednych hodnot var pointsComputeInSQL = _db . T i c k e t . Where ( t => t . PurchaseDate >= model . S t a r t D a t e && t . PurchaseDate <= model . EndDate && t . TicketType ! = TicketType . Account ) . GroupBy ( g => g . ProgramID ) . S e l e c t ( k => new { key = k . F i r s t O r D e f a u l t ( ) . Program . Name, value = k . Count ( ) } ) . T o D i c t i o n a r y ( key => key . key , value => ( double ) value . value ) ; Zdrojový kód 5.2: Změna způsobu dotazování pomocí LINQ. Nejrychlejším přístupem k datům je úplné obejití Entity Frameworku a práce přímo s SQL dotazem, který je vidět ve zdrojovém kódu 5.3. V grafu se jedná o sloupce Native SQL. Získání stejných výsledků touto cestou bylo dokončeno téměř vždy rychlostí pod 100 ms. Nevýhodou tohoto přístupu je ale přibližně dvojnásobná náročnost na řádky zdrojového kódu a nutnost práce přímo s SQL kódem, který se ve zdrojovém kódu hůře ladí. V takto napsaném kódu se případné chyby hledají mnohem hůře. DECLARE @p1 d a t e t i m e = CAST( ’2012 −12 −01 ’ AS d a t e t i m e ) DECLARE @p2 d a t e t i m e = CAST( ’2012 −12 −07 2 3 : 5 9 : 5 9 ’ AS d a t e t i m e ) SELECT p . Name, Count FROM ( SELECT p . ID as ProgramID , COUNT( * ) AS Count FROM T i c k e t t INNER JOIN Program p ON t . ProgramID = p . ID WHERE t . PurchaseDate BETWEEN @p1 AND @p2 AND t . TicketType < 2 GROUP BY p . ID ) AS t a b 1 INNER JOIN Program p ON p . ID = t a b 1 . ProgramID Zdrojový kód 5.3: SQL dotaz pro výpočet poměru zakoupených lístků. Část zrychlení i v tomto případě může být způsobeno využitím mezipaměti (kešování) na straně SQL Serveru, které se v případě počítání výsledků až v paměti nevyužije. Zvolenou variantou pro výpočty na stránce Statistika se stala úprava provedená v druhém kroku spolu s užitím kešování výsledků popisovaném výše. SQL dotazy generované prvními dvěma přístupy i přímý dotaz v poslední variantě jsou součástí přílohy E. 5.5.3 Průzkum exekučního plánu Většina současných databázových systémů nabízí nějakou možnost záznamu pomalých dotazů, případně průzkum chování konkrétního dotazu. V případě použitého MS SQL Serveru lze využít i možností SQL Management Studia. Rozdíly rychlostí různých metod v předchozí kapitole vedly k detailnějšímu průzkumu právě pomocí Management Studia. V tomto nástroji bylo využito možnosti zobrazení exekučních plánů pro SQL dotazy generované v předchozí kapitole (v nástroji například klávesová zkratka Ctrl+L, nebo položka 52

5. Aplikace nástrojů pro měření a ladění výkonu menu Query – Display Estimated Execution Plan). Zobrazení exekučního plánu přináší též tipy na zlepšení výkonu, ve všech třech případech to bylo přidání indexu. Zajímavostí může být, že LINQ s výpočtem v databázi a nativní dotaz generovaly podobný exekuční plán a nabídnutý index (viz zdrojový kód 5.4) pro zlepšení výkonu byl v obou případech stejný (s údajným dopadem až 84 % času). Tento fakt dokazuje ekvivalenci obou řešení. Velikost indexu byla na databázi s demonstračním provozem 3,6 MB, přičemž celková velikost databáze byla přibližně 120 MB. CREATE NONCLUSTERED INDEX IX_PurchaseDate_TicketType_inc_ProgramID ON [ dbo ] . [ T i c k e t ] ( [ PurchaseDate ] , [ TicketType ] ) INCLUDE ( [ ProgramID ] ) Zdrojový kód 5.4: Navržený index pro tabulku Ticket.

5.5.4 Umístění databáze na SSD disk V případě aplikací s intenzivním přístupem do databáze lze využít rychlosti SSD disků a soubory databáze umístit na ně. Výhodou SSD disků je absence potřeby vystavování hlaviček na konkrétní místo na disku a tím pádem okamžité čtení požadovaných dat. Rozdíl rychlostí systémového disku oproti druhému datovému disku je znázorněn v tabulce 5.5. Metrika / Disk Přístup pro náhodné čtení (ms) Průměrná rychlost čtení (MB/s) Využití procesoru (%)

HDD 15 127,5 15

SSD 0,1 194 10

Tabulka 5.5: Srovnání rychlostí použitého HDD a SSD. Nevýhodou SSD disků je ale pořád jejich vyšší cena a v případě intenzivních zápisů také mnohem menší živostnost, než v případě klasických disků. Z těchto důvodů hlavní měření probíhalo se soubory umístěnými na běžném HDD. Pro porovnání rychlostí byl ale hlavní soubor databáze SalesTerminal.WebApp.Data.SalesTerminalDb umístěn po dobu srovnávacích měření i na SSD disk. Podrobnější srovnání lze nalézt například ve studii provedené společností DELL [36]. 5.5.5 Nastavení Entity Frameworku Tato ladící technika se netýká přímo webové aplikace, ale programu SalesTerminal.DatabaseFiller pro plnění databáze simulačními daty. Při první implementaci tohoto programu docházelo postupně ke značnému zpomalení plnění. První iterace proběhly v řádu sekund, třicáté a další iterace již ale trvaly řádově minuty. Příčinou takto značné degradace výkonu je samotný Entity Framework, který sleduje a kešuje veškeré změny spravovaných objektů. Důvody a popis této funkcionality jsou například v článku [37] rozebírajícím dopady EF 5 na výkon software. Řešením v tomto případě bylo vypnutí sledování změn na objektech a použití nového kontextu databáze pro každý simulovaný den. 53

5. Aplikace nástrojů pro měření a ladění výkonu 5.5.6 Použití komprese Testováno bylo také chování s povolenou kompresí dynamického obsahu na straně IIS serveru. Zapnutí této vlastnosti mělo ale negativní dopad na výkon kvůli vyšší spotřebě procesoru. Zisk v minimalizaci objemu přenesených dat byl nepatrný, takže tato vlastnost nebyla dále používána. 5.5.7 Svazování a minifikace skriptů a stylů ASP.NET přišel ve verzi 4.5 (v době psaní práce nejnovější) s novinkou týkající se svazování a minifikace skriptů a stylů [38]. Jedná se například o soubory JavaScriptu .js nebo kaskádových stylů .css. Podobná technika byla dostupná již dříve v podobě předgenerovaných minifikovaných souborů, práce s minifikací je ale v této verzi mnohem pohodlnější. Myšlenkou pro zrod této funkcionality je fakt, že většina webových prohlížečů omezuje maximální počet spojení, které navazují vůči jednomu serveru. Celková doba čekání v případě množství menších souborů tak může být mnohem delší, než vlastní doba stahování. ASP.NET proto v této verzi přináší možnost určit seznamy skriptů nebo stylů, které spolu nějakým způsobem souvisí (například jsou důležité pro určitou funkci na stránce) a automaticky je při stahování spojuje do jednoho. Toto vylepšení tak přináší omezení potřebného počtu požadavků. Další a související novinkou je minifikace, kdy ASP.NET odstraní pro běh nepotřebné součásti kódu, tj. komentáře a bílé znaky (tabulátory, nové řádky, duplikované mezery kvůli zarovnání, ...). Dalším krokem minifikace je pak přejmenování parametrů a názvů proměnných. Tento krok zmenší velikost výsledného souboru a opět tak zrychlí jeho přenos ke klientovi. Povolení minifikace a svazování je velmi jednduché a přitom účinné, provádí se jedním příkazem BundleTable.EnableOptimizations = true; v souboru Global.asax.cs. V případě svazku s jedním skriptem je využito alespoň funkce minifikace. Funkce povolena NE ANO

Počet požadavků 17 6

Velikost dat 351 KB 137 KB

Stažení stránky 253 ms 207 ms

Tabulka 5.6: Srovnání parametrů při zapnuté a vypnuté minifikaci a svazování. Kombinace těchto kroků dokáže zvýšit rychlost odezvy na první požadavek na tyto zdroje a ušetřit šířku pásma jak na straně klienta, tak výrazněji na straně serveru. Vlastní test na vyvíjené aplikaci byl proveden nad sadou stylů potřebných pro knihovnu jQuery4 . Snímky obrazovky z vývojářských nástrojů prohlížeče Google Chrome umístěné v příloze D a hodnoty tabulce 5.6 ukazují přínos tohoto postupu ve všech zmíněných směrech (počet potřebných spojení, doba načítání, velikost dat). Pro snímky byla použita přibližná pozorovaná průměrná hodnota. 4. jQuery je knihovna napsaná v jazyce JavaScript. Použití zjednodušuje procházení struktury HTML, zpracování událostí, animace a další interní činnosti moderních webových stránek [39].

54

5. Aplikace nástrojů pro měření a ladění výkonu 5.5.8 Využití Content Delivery Network (CDN) Content Delivery Network, neboli síť pro doručování obsahu, je skupina serverů rozmístěných v různých datových centrech po světě. Tyto servery lze využívat i pro zrychlení načítání webových stránek. Pravděpodobně nejznáměnším komerčním zástupcem ze sítí tohoto typu je Akamai [40]. V případě webových stránek lze s využitím CDN obejít limit počtu otevřených spojení vůči jednomu serveru a některé typy dat načítat z této sítě. Typicky se toho využívá pro JavaScriptové knihovny jako je jQuery. Demonstrační aplikace má spíše intranetový charakter, proto u ní této možnosti využito nebylo.

5.6

Srovnání výkonu s počáteční implementací

Graf na obrázku 5.4 a tabulka 5.7 ukazují výsledky měření použitého na počátku v kapitole 5.3.2 po implementaci zlepšení z předchozí kapitoly. Ladění výkonu bylo velmi úspěšné, například průměrná odezva akce Sell se zmenšila z 85 na 11 ms. Průměrné využití procesoru kleslo na hodnoty okolo 20 %. Nejvíce zrychlena byla akce Sale, u které je kešována celá stránka. V případě databáze umístěné na SSD disk se rychlosti ještě nepatrně zlepšily, a to v průměru o 1 ms. U tohoto scénáře muselo být paradoxně přepnuto schéma napájení počítače na Vysoký výkon, neboť aplikace nepřesáhla nastavené meze pro běh procesoru na vyšší frekvenci. U jiných měření toto nastavení nebylo třeba měnit, neboť byl procesor dostatečně vytěžován a k přepnutí došlo automaticky. Pokud bylo ponecháno schéma napájení na Vyvážené, hodnoty vytížení procesoru byly pod 30 % a průměrná doba odezvy byla 15 ms. Název testu Use ticket Login page Login Sale Single Ticket Multi Ticket Account ticket Repetition count setting Amount setting Sell

Poč. vzorků 27713 80 80 2173 734 720 699 720 691 2125

Průměr (ms) 11 4 105 4 12 11 11 9 9 11

Std. odch. (ms) 23 0 4 19 22 6 18 19 22 17

90% perc. (ms) 17 5 111 3 12 12 10 9 17 18

Celkem

35735

10

22

17

Tabulka 5.7: Údaje z měření na obrázku 5.4 (po ladění). Obdobně jako při předchozím případě bylo dále měřeno chování aplikace za vyššího zatížení, a to 400 prodejců a 1000 zařízení. Průměrná doba odezvy klesla na cca 1 sekundu. Umístění databáze na rychlejší SSD disk zde mělo mnohem větší dopad, než se základním počtem uživatelů. Přínos rychlého náhodného čtení přinesl zrychlení v průměru přibližně na 55


Obrázek 5.4: Výstup z měření prodeje a používání lístků po ladění výkonu. Poznámka pro černobílý tisk: horní linka je procentuální vytížení procesoru na měřeném počítači, pod ní je doba odezvy akce Sell, dále doba odezvy akce Use ticket, nejníže pak čas pro výpočet stránky měřený aplikací. 350 ms. V tomto případě se dostával do potíží už i JMeter, zejména pokud bylo okno přepnuto na zobrazování real-time grafů. Minimalizací nebo přepnutím jiného pohledu v aplikaci bylo vše v pořádku. Se všemi provedenými úpravami byl úzkým místem stále procesor. Rozložení zátěže se nepatrně změnilo, jak je vidět v tabulce 5.8. Na SQL Server patrně putuje více požadavků, tudíž v tomto případě spotřebovává více procesoru i paměti. Proces iisexpress.exe sqlserv.exe

CPU (% využití) 76,5 9,4

RAM (pracovní sada) 234 MB 335 MB

Tabulka 5.8: Nejvíce vytěžující procesy po ladění aplikace.

5.6.1 Detekce maximálního počtu uživatelů Pro určení maximálního počtu uživatelů bylo využito zátěžového testu ve Visual Studiu s volbou Goal Based Load Pattern. Doba běhu testu byla ponechána na deset minut, inkrement i dekrement uživatelů byl nastaven na hodnotu 5. Určovací hodnotou pro zvyšování nebo 56

5. Aplikace nástrojů pro měření a ladění výkonu snižování počtu uživatelů bylo vytížení procesoru s cílovým rozsahem mezi 70 a 90 %. Testy byly v tomto případě spouštěny v poměru 30 % prodejců a 70 % zařízení. Výsledný graf zachycený po konci měření je vidět na obrázku 5.5 a lze z něj vyčíst, že za dodržení stanovených podmínek byl maximální počet virtuálních uživatelů 275.

Obrázek 5.5: Nastavení scénáře pro detekci maximálního počtu uživatelů pro dané meze vytížení procesoru.

5.6.2 Možnosti zisku dalšího výkonu I přes veškeré úpravy byl na použitém počítači stále úzkým místem procesor, respektive Entity Framework, který jej nejvíce využívá. Pro další zvyšování výkonu by tak bylo nutné nasadit aplikaci na server obsahující větší množství výpočetních jader – strategie Scale-Up. Druhou variantou by byla strategie Scale-Out, kdy by se mohlo jednat o použití farmy více aplikačních serverů a rozložení zátěže mezi ně. SQL Server by mohl být na samostatném serveru.

57

6 Závěr Cílem diplomové práce bylo seznámení se s výkonem softwarových systémů a nástroji používanými pro jeho měření s upřednostněním volně dostupných nástrojů. Ke srovnání těchto nástrojů měly být uvedeny v praxi použitelné techniky a taktiky ladění výkonnosti software s cílem tyto techniky aplikovat na demonstrační aplikaci za použití vybraného nástroje. Pro plné seznámení s atributem výkonosti softwarových systémů bylo nastudováno množství literatury a článků zabývající se touto problematikou z pohledu teoretického i praktického. Teoretických zdrojů bylo využito zejména ve druhé a na počátku třetí kapitoly, kde jsou uvedeny taktiky a techniky ladění výkonu a také vybrané metodiky vývoje software, které se výkonu dotýkají. Druhá část třetí kapitoly představuje vybrané nástroje pro měření a ladění výkonu, a je zakončena jejich srovnáním. Pro praktickou demonstraci analýzy a ladění výkonu je ve čtvrté kapitole představena demonstrační aplikace. Vybraným nástrojem pro měření výkonu byl volně dostupný Apache JMeter. Kromě tohoto nástroje výborně posloužilo také Visual Studio, v němž byla aplikace vyvíjena. Po implementaci základní funkcionality aplikace bylo prováděno množství výkonnostně zaměřených testů, zejména testy s účelem odhalit výkonnostní rezervy aplikace. Tyto kroky popisuje kapitola pátá. Z prováděných měření vyplynulo jasné poučení. Nejvhodnější metodou jak dosáhnout zrychlení výpočtu je ho vůbec neprovádět. Výkon demonstrační aplikace nejvíce posílila implementace kešování, nebo se alespoň největší měrou projevila do výsledků při průběžných měřeních. Jelikož po aplikaci všech ladících kroků byl nejvytěžující součástí měřené aplikace Entity Framework, bylo by zajímavým dalším krokem srovnání různých přístupů v tomto frameworku (Code-First, Model-First, Database-First), připadně použití úplně jiného řešení. Přečtením tohoto textu může čtenář získat základní přehled o problematice výkonnosti software, prohlédne i do používaných nástrojů pro ladění výkonu, zejména zvoleného Apache JMeteru.

58

Literatura [1] WIKIPEDIA. Service-level agreement — Wikipedia, The Free Encyclopedia, 2012. Dostupné z: http://en.wikipedia.org/w/index.php?title=Service-level_ agreement&oldid=528608476. [2] Intel. Intel Hyper-Threading Technology [online]. 2012. [cit. 29.10.2012]. Dostupné z: http: //www.intel.com/technology/platform-technology/hyper-threading/. [3] BASS, L. – CLEMENTS, P. – KAZMAN, R. Software architecture in practice. Addison-Wesley, 2nd edition, 2003. ISBN 0-321-15495-9. [4] LIU, H. H. Software Performance and Scalability: A Quantitative Approach. Wiley, 2009. ISBN 978-0470462539. Amdahl’s law — Wikipedia, The Free Encyclopedia [online]. 2012. [5] WIKIPEDIA. [cit. 10.10.2012]. Dostupné z: http://en.wikipedia.org/w/index.php?title= Amdahl%27s_law&oldid=515929929. [6] CORTELLESSA, V. – MARCO, A. D. – INVERARDI, P. Model-Based Software Performance Analysis. Springer, 2011. ISBN 978-3-642-13620-7. [7] TOP 500 Supercomputers Site. Titan - Cray XK7 [online]. 2012. [cit. 12.12.2012]. Dostupné z: http://www.top500.org/system/177975. [8] MALKOWSKI, S. – HEDWIG, M. – PU, C. Experimental evaluation of N-tier systems: Observation and analysis of multi-bottlenecks. In Workload Characterization, 2009. IISWC 2009. IEEE International Symposium on, s. 118 –127, oct. 2009. doi: 10.1109/IISWC.2009. 5306791. [9] Object Management Group. UML [online]. 2012. [cit. 23.10.2012]. Dostupné z: http: //www.omg.org/spec/UML/. [10] Visual Paradigm. UML CASE tool for software development [online]. 2012. [cit. 28.10.2012]. Dostupné z: http://www.visual-paradigm.com/product/vpuml/. [11] StarUML. StarUML – The Open Source UML/MDA Platform [online]. 2012. [cit. 28.10.2012]. Dostupné z: http://staruml.sourceforge.net. [12] Object Management Group. UML Profile Specifications [online]. 2012. [cit. 23.10.2012]. Dostupné z: http://www.omg.org/technology/documents/profile_catalog. htm. [13] Object Management Group. UML Profile for Schedulability, Performance, and Time Specification [online]. 2012. [cit. 29.10.2012]. Dostupné z: http://www.omg.org/spec/ SPTP/1.1/PDF. 59

Literatura [14] Object Management Group. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems [online]. 2012. [cit. 29.10.2012]. Dostupné z: http://www.omg.org/ spec/MARTE/1.1/PDF. [15] DYBÅ, T. – DINGSØYR, T. Empirical studies of agile software development: A systematic review. Information and Software Technology. 2008, 50, 9–10, s. 833 – 859. ISSN 0950-5849. doi: 10.1016/j.infsof.2008.01.006. Dostupné z: http://www.sciencedirect.com/ science/article/pii/S0950584908000256. [16] Computerworld. Extreme programming [online]. 2001. [cit. 4.11.2012]. Dostupné z: http: //www.computerworld.com/s/article/66192/. [17] WILLIAMS, L. – MAXIMILIEN, E. – VOUK, M. Test-driven development as a defectreduction practice. In Software Reliability Engineering, 2003. ISSRE 2003. 14th International Symposium on, s. 34 – 45, 2003. doi: 10.1109/ISSRE.2003.1251029. [18] Apache Software Foundation. Apache JMeterTM [online]. 2012. [cit. 12.10.2012]. Dostupné z: http://jmeter.apache.org/. [19] Kolektiv autorů. JMeter Plugins [online]. 2012. [cit. 3.12.2012]. Dostupné z: http:// code.google.com/p/jmeter-plugins/. [20] BlazeMeter. The Load Testing Cloud [online]. 2012. [cit. 3.12.2012]. Dostupné z: http: //blazemeter.com/. [21] The Grinder. The Grinder, a Java Load Testing Framework [online]. 2012. [cit. 12.10.2012]. Dostupné z: http://grinder.sourceforge.net/. [22] SEDLÁČEK, J. – HŮRKA, T. VisualVM [online]. 2012. [cit. 4.11.2012]. Dostupné z: http://visualvm.java.net/. [23] Radview Software Inc. WebLOAD: Web Application Load and Stress Testing Solution [online]. 2012. [cit. 22.10.2012]. Dostupné z: http://www.radview.com/. [24] Radview Software Inc. WebLOAD: Architecture [online]. 2012. [cit. 23.10.2012]. Dostupné z: http://www.radview.com/product/Product.aspx. [25] Hewlett-Packard Development Company, L.P. Load Testing, Software Testing Tool, HP LoadRunner [online]. 2012. [cit. 22.10.2012]. Dostupné z: http://hp.com/go/ loadrunner. [26] Hewlett-Packard Development Company, L.P. Performance Center 11.50 and LoadRunner 11.50 Protocol Bundles [online]. 2012. [cit. 29.10.2012]. Dostupné z: http://h20195. www2.hp.com/V2/GetPDF.aspx/4AA1-3191ENW.pdf. [27] Hewlett-Packard Development Company, L.P. A closer look at HP LoadRunner software [online]. 2012. [cit. 29.10.2012]. Dostupné z: https://ssl.www8.hp.com/ww/en/ secure/pdf/4aa3-3960enw.pdf. 60

Literatura [28] YourKit, LLC. Java Profiler - .NET Profiler - The profilers for Java and .NET professionals [online]. 2012. [cit. 22.10.2012]. Dostupné z: http://www.yourkit.com/. [29] Microsoft Corporation. Most Valuable Professionals [online]. 2012. [cit. 4.11.2012]. Dostupné z: http://mvp.microsoft.com/. [30] NetBeans. NetBeans profiler [online]. 2012. [cit. 28.10.2012]. Dostupné z: http:// profiler.netbeans.org/. [31] Microsoft Corporation. Beginners Guide to Performance Profiling [online]. 2012. [cit. 28.10.2012]. Dostupné z: http://msdn.microsoft.com/en-us/library/ ms182372.aspx. [32] AppDynamics. Application Performance Management | Web Application Monitoring Software [online]. 2012. [cit. 23.10.2012]. Dostupné z: http://www.appdynamics.com/. [33] Selenium. Web Browser Automation [online]. 2012. [cit. 13.11.2012]. Dostupné z: http: //seleniumhq.org. [34] SANDERSON, S. Partial Output Caching in ASP.NET MVC [online]. 2008. [cit. 5.12.2012]. Dostupné z: http://blog.stevensanderson.com/2008/10/15/ partial-output-caching-in-aspnet-mvc/. [35] Microsoft Corporation. LINQ (Language-Integrated Query) [online]. 2012. [cit. 27.12.2012]. Dostupné z: http://msdn.microsoft.com/en-us/library/vstudio/ bb397926.aspx. [36] KASAVAJHALA, V. SSD vs HDD Price and Performance Study [online]. 2012. [cit. 27.12.2012]. Dostupné z: http://www.profesorweb.es/wp-content/ uploads/2012/11/ssd_vs_hdd_price_and_performance_study.pdf. [37] OBANDO, D. – DETTINGER, E. Performance Considerations for Entity Framework 5 [online]. 2012. [cit. 5.12.2012]. Dostupné z: http://msdn.microsoft.com/en-us/data/ hh949853.aspx. [38] The Official Microsoft ASP.NET Site. Bundling and Minification [online]. 2012. [cit. 23.12.2012]. Dostupné z: http://www.asp.net/mvc/tutorials/mvc-4/ bundling-and-minification. [39] JQUERY. jQuery, 2012. Dostupné z: http://jquery.com/. [40] AKAMAI. Akamai, 2012. Dostupné z: http://www.akamai.com/. [41] Kolektiv autorů. Manifest Agilního vývoje software [online]. 2012. [cit. 30.10.2012]. Dostupné z: http://agilemanifesto.org/iso/cs/.

61

A Manifest Agilního vývoje software Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 12 principů agilního vývoje software Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. Hlavním měřítkem pokroku je fungující software. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.

Zdroj: [41].

62

B Obsah databáze při založení Následující objekty jsou vytvořeny automaticky při nasazení aplikace. ∙

Uživatelé Kompletní seznam přihlašovacích jmen a hesel je vidět v příloze users.csv. Navíc k těmto uživatelům patří ještě uživatel Manager s heslem manager, který má aplikační roli manažera.

∙

Programy a Zařízení 4 demonstrační programy a zařízení.

∙

Nastavení Položky potřebné pro nastavení aplikace.

63

C Snímky obrazovky profileru a testů z Visual Studia

Obrázek C.1: Výstup z profileru Visual Studia 2012 před laděním výkonu.

64

C. Snímky obrazovky profileru a testů z Visual Studia

Obrázek C.2: Výstup z profileru Visual Studia 2012 po ladění výkonu.

65


Obrázek C.3: Scénář SalesPerson ve Visual Studiu.

66


Obrázek C.4: Scénář Device ve Visual Studiu.

Obrázek C.5: Kombinace předchozích testů do testu zátěžového.

67

D Snímky obrazovky průběhu stahování stránky v Google Chrome

Obrázek D.1: Průběh stažení stránky prodeje se zapnutou webovou optimalizací.

68

D. Snímky obrazovky průběhu stahování stránky v Google Chrome

Obrázek D.2: Průběh stažení stránky prodeje bez zapnuté webové optimalizace.

69

E Obsah archivu ∙

Aplikace popsané v kapitole 4.2.2 včetně scénářů z Visual Studia.

∙

Testovací scénáře pro Apache JMeter včetně seznamu uživatelů.

∙

SQL dotaz pro generování dostupných lístků – určeno jako zdroj pro testovací scénář.

∙

SQL dotazy generované různými přístupy při generování statistik, viz kapitola 5.5.2.

70

012345

Recommend Documents