ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY
ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˚ ´ STAV INTELIGENTNI´CH SYSTE´MU U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
ˇ ENI´ VY ´ KONNOSTI VYBRANY ´ CH NA ˚ ´ STROJU MEˇR DROOLS
ˇ SKA ´R ´ PRA´CE BAKALA BACHELOR’S THESIS
AUTOR PRA´CE AUTHOR
BRNO 2011
´ ˇ IROKY PETR S
ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY
ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˚ ´ STAV INTELIGENTNI´CH SYSTE´MU U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS
ˇ ENI´ VY ´ KONNOSTI VYBRANY ´ CH NA´STROJU ˚ MEˇR DROOLS PERFORMANCE MEASUREMENT OF SELECTED DROOLS TOOLS
ˇ SKA´ PRA´CE ´R BAKALA BACHELOR’S THESIS
AUTOR PRA´CE
´ ˇ IROKY PETR S
AUTHOR
VEDOUCI´ PRA´CE SUPERVISOR
BRNO 2011
ˇ K LETKO Ing. ZDENE
Abstrakt Testování výkonu aplikací je velmi často opomíjeno. Tato práce popisuje proces testování výkonu nástrojů Drools Expert a Drools Fusion. Drools je platforma pro integraci podnikové logiky, moduly Expert a Fusion jsou její součástí. Expert je na pravidlech založený expertní systém, Fusion slouží k detekci a zpracování událostí. Testy jsou navrženy a implementovány především za účelem nalezení výkonnostní regrese mezi různými verzemi nástrojů Expert a Fusion. V závěru práce jsou diskutovány výsledky pro dvě konkrétní verze těchto nástrojů.
Abstract Performance testing is often overlooked. This thesis describes the performance testing of the Drools Expert and Drools Fusion tools. Drools is a Business Logic Integration Platform. Expert and Fusion are parts of this platform, which provide rule based expert system and event processing capabilities respectively. Tests are designed and implemented with main focus on finding performance regression between different versions of Expert and Fusion tools. Results for two versions of these tools are discussed at the end of the thesis.
Klíčová slova testování výkonu, expertní systém, Drools, Expert, Fusion
Keywords performance testing, expert system, Drools, Expert, Fusion
Citace Petr Široký: Měření výkonnosti vybraných nástrojů Drools, bakalářská práce, Brno, FIT VUT v Brně, 2011
Měření výkonnosti vybraných nástrojů Drools Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením pana Zdeňka Letka. ....................... Petr Široký 18. května 2011
Poděkování Rád bych poděkoval odbornému vedoucímu Zdeňku Letkovi a technickému vedoucímu Lukáši Petrovickému za cenné rady a věcné připomínky při řešení bakalářské práce.
c Petr Široký, 2011.
Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.
Obsah 1 Úvod
2
2 Úvod do použitých technologií 2.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Expertní systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 4
3 Projekt Drools 3.1 Drools Expert . . . . . . . . . . . . . . . . . . . . 3.1.1 Standard JSR94 . . . . . . . . . . . . . . 3.1.2 Struktura systému Expert . . . . . . . . . 3.1.3 Vlastnosti pravidly řízeného programování 3.2 Drools Fusion . . . . . . . . . . . . . . . . . . . . 3.2.1 Komplexní zpracování událostí . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
5 6 6 6 8 9 9
4 Testování výkonu aplikací 4.1 Výkon aplikace a jak ho měřit . . . . . 4.1.1 Jak výkon měřit? . . . . . . . . 4.1.2 Typy výkonnostních testů . . . 4.2 Proces testování výkonu . . . . . . . . 4.2.1 Určení požadavků na výkon . . 4.2.2 Analýza a návrh testů . . . . . 4.2.3 Implementace a spuštění testů 4.2.4 Zpracování a analýza výsledků
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
10 10 10 11 12 12 12 13 14
Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
15 15 16 19 19 21 21
. . . . . . . .
. . . . . . . .
5 Testování výkonu Drools Expert a Drools 5.1 Analýza, návrh testů a testovací prostředí 5.1.1 Návrh transakcí a testů . . . . . . 5.1.2 Testovací prostředí . . . . . . . . . 5.2 Implementace a spuštění testů . . . . . . . 5.3 Analýza výsledků . . . . . . . . . . . . . . 5.3.1 Analýza po skončení testů . . . . . 6 Závěr
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
25
1
Kapitola 1
Úvod S pravidly se setkáváme dnes a denně v mnoha oborech lidské činnosti. Jako příklad může sloužit proces zjišťování, zda má klient nárok na půjčku. Instituce, která půjčku zajišťuje, má sadu pravidel, které musí klient splňovat, jestliže má být půjčka schválena. Klient musí být plnoletý, nesmí mít předchozí dluhy, atp. Platforma Drools slouží mimo jiné k snadnější správě a implementaci těchto pravidel. Měření a testování výkonu je stále velmi opomíjeno ve srovnání např. s funkčním nebo systémovým testováním. Důvody jsou různé. Od nedostatku časových či finančních prostředků, přes přesvědčení manažerů, že testovat výkon je zbytečné, až po nedostatek kvalifikovaných lidí, kteří jsou schopní testování provést. Cílem této práce je navrhnout a implementovat prostředí pro měření a testování výkonu nástrojů Drools Expert a Drools Fusion a implementovat sadu výkonnostních testů, které budou sloužit k odhalení výkonnostní regrese mezi různými verzemi těchto systémů. Práce je rozdělena do pěti kapitol. Následující kapitola popisuje technologie, které jsou v rámci práce používány. Jedná se o expertní systémy a platformu Java. Ve třetí kapitole jsou uvedeny základní informace o projektu Drools. Podrobněji jsou popsány systémy Expert a Fusion, které jsou předmětem testování. Čtvrtá kapitola si klade za cíl seznámit čtenáře s testováním výkonu obecně. Definuje pojem výkon, dále popisuje, jak výkon měřit, jaké jsou druhy výkonnostních testů a a také jak při testování výkonu postupovat. Pátá kapitola popisuje proces testování výkonu systémů Expert a Fusion. Poslední kapitolou je závěr, ve kterém je uvedeno zhodnocení práce, dosažené výsledky a návrhy na další možné pokračování práce.
2
Kapitola 2
Úvod do použitých technologií 2.1
Java
Java [6] je objektově orientovaný programovací jazyk, představený společností Sun Microsystems v roce 1995. Pojem Java zároveň označuje celou výpočetní platformu, jejíž součástí je množství softwarových produktů a specifikací, které společně tvoří systém pro vývoj a běh multiplatformních aplikací. Na této platformě je postavena celá řada aplikací od jednoduchých nástrojů přes hry až pro podnikové aplikace. Java jako platforma se dále dělí na: Java ME (Micro Edition). Platforma navržená pro vestavěné systémy (embedded systems), jako jsou např. mobilní telefony nebo PDA. Java SE (Standard Edition). Platforma určená k vývoji aplikací na klasických desktopových počítačích a podobných zařízeních. Java EE (Enterprise Edition) [8]. Platforma určená pro vývoj podnikových systémů, tzv. enterprise aplikací. Staví na Java SE a přidává funkcionalitu, která umožňuje vývoj a nasazení distribuovaných, více vrstvých a modulárních aplikací. Hlavní částí celé platformy Java je virtuální stroj (Java Virtual Machine, JVM). Zdrojový kód programu není překládán přímo do binárního kódu dané platformy, ale je přeložen do platformně nezávislého mezistupně zvaného bytekód. Ten je poté interpretován virtuálním strojem. Programátor je takto odstíněn od odlišností různých hardwarových a softwarových platforem a jednou napsaný kód lze spustit všude tam, kde je k dispozici JVM. Hlavní nevýhodou je vyšší paměťová náročnost aplikací, protože s každou aplikací se musí zároveň spustit virtuální stroj. Důležitou charakteristikou JVM je automatická správa paměti. Správce paměti se tak stará o přidělování a uvolňování paměti a programátor je od těchto činností odstíněn. Objekty, které již nejsou z programu dostupné, jsou automaticky z paměti odstraněny. Tomuto procesu se říká, v doslovném překladu, sběr odpadků“ (gargabe collecting, GC) ” a je plně v režii virtuálního stroje. Virtuální stroj Javy také definuje různé datové oblasti, které jsou využívány při běhu programu. Některé tyto oblasti jsou vytvořeny při startu JVM a odstraněny pouze při ukončení celého JVM. Další jsou specifické pro jednotlivá vlákna a vytvářejí resp. odstraňují se při vytváření resp. ukončování vklákna [13].
3
2.2
Expertní systémy
Expertní systémy [7] jsou systémy umělé inteligence, které jsou vytvářeny s cílem napodobit či simulovat rozhodování lidského experta. Na základě vstupních informací a uložených znalostí je systém schopen odvodit informace nové, stejně jako to dělá lidský expert. Příkladem expertního systému je MYCIN [18]. Byl vytvořen v 90. letech minulého století a používali ho lékaři jako výpomoc při určovaní diagnózy pacienta. Pomocí otázek typu ano/ne byl schopen zjistit, jaké diagnózy připadají pro daného pacienta v úvahu. Expertní systém zpravidla obsahuje následující části [7, 5]: Usuzovací podsystém. Usuzovací podsystém je jádrem celého expertního systému. Obsahuje rozhodovací algoritmus, který určuje, jaká pravidla mohou být aktivována, tzn. u jakých pravidel jsou splněny podmínky. Tato pravidla jsou poté umístěna do agendy, a ta rozhodne, v jakém pořadí budou pravidla aktivována. Báze znalostí. Báze znalostí je místo, kde jsou uloženy znalosti systému. Znalosti jsou typicky reprezentovány jako kolekce pravidel typu when-then (nebo též if-then). Část when se často označuje jako levá strana pravidla a obsahuje podmínky, které je nutné splnit předtím, než může být samotné pravidlo aktivováno. Část then je pravá strana pravidla a obsahuje akce, které budou vykonány v případě, že bylo pravidlo aktivováno. Pracovní paměť. V pracovní paměti systém uchovává aktuálně známé informace (doménové objekty), kterým se také jinak říká fakty (facts). Fakty jsou typicky vkládány před spuštěním usuzovacího podsystému. Další možností jak fakty vkládat, upravovat a odstraňovat je v rámci akcí po aktivaci pravidla. Agenda. V systému s velkým počtem pravidel a faktů může docházet k tomu, že po vložení nových faktů do pracovní paměti jsou splněny podmínky u více pravidel zároveň (tzn. že tato pravidla mohou být aktivována); jedná se o konflikt pravidel. Agenda řídí pořadí spouštění těchto konfliktních pravidel s využitím strategie řešení konfliktů (conflict resolution strategy). Uživatelské rozhraní. Přes uživatelské rozhraní lze s expertním systémem komunikovat a ovládat ho. Typicky lze přes toto rozhraní vkládat a upravovat fakty v pracovní paměti a spouštět usuzovací podsystém.
4
Kapitola 3
Projekt Drools Drools [3] je platforma pro integraci podnikové logiky (Business Logic Integration Platform). Jedná se o projekt s otevřeným zdrojovým kódem, který je napsán v Javě a jeho cílem je vytvořit jednotnou platformu pro behaviorální modelování. K dosažení tohoto cíle Drools poskytují tři vzájemně se doplňující techniky modelování: • řízení podnikových pravidel (Business Rules Management), • řízení podnikových procesů (Business Processes Management, BPM), • komplexní zpracování událostí (Complex Event Processing, CEP). Projekt jako takový je rozdělen do 5 dílčích podprojektů: Expert, Fusion, Guvnor, Flow a Planner. Následující seznam obsahuje základní informace o každém z modulů. Podkapitoly 3.1 a 3.2 poté popisují moduly Expert a Fusion podrobněji, protože souvisejí s tématem práce. • Expert je nejstarší a zároveň stěžejní modul celé platformy. Jedná se o expertní systém založený na pravidlech. Tvoří jádro celé platformy a ostatní moduly staví na tomto systému. • Fusion je modul, který přidává možnost detekce, výběru a zpracování významných událostí ze skupiny nebo proudu událostí. • Guvnor1 je systém primárně určen pro správu pravidel. Jedná se o webovou aplikaci, která umožňuje např. vytvářet, upravovat a testovat pravidla. Viz [3]. • Flow2 slouží k modelování, řízení a monitorování pracovních nebo podnikových procesů. Nedávno byl modul Flow přejmenován na jBPM 5. • Planner3 slouží k řešení plánovacích úloh pomocí metaheuristických algoritmů, jako jsou tabu vyhledávání a simulované žíhání. Jako příklad plánovací úlohy lze uvést problém obchodního cestujícího4 . 1
http://www.jboss.org/drools/drools-guvnor http://www.jboss.org/drools/drools-flow 3 http://www.jboss.org/drools/drools-planner 4 http://www.tsp.gatech.edu/index.html 2
5
3.1
Drools Expert
Drools Expert je tzv. Business Rules Engine (dále jen BRE), což je expertní systém založený na pravidlech, který se využívá v podnikových aplikacích. V rámci platformy Drools se stará o řízení a vyhodnocování podnikových pravidel.
3.1.1
Standard JSR94
Standard JSR94 [12] definuje jednoduché rozhraní pro programování aplikací (Application Programming Interface, API) pro přístup k BRE z Java SE nebo Java EE aplikací. Standard popisuje, jak: registrovat a odregistrovat pravidla, analyzovat pravidla, procházet metadata pravidel, aktivovat pravidla, získávat a filtrovat výsledky. Naopak JSR94 nedefinuje, a tím pádem nechává na jednotlivých implementacích, např. následující: samotné běhové prostředí (rule engine), tok vykonávání pravidel, jazyk, kterým se pravidla popisují, mechanismus pro nasazení (deployment) v Java EE. Drools Expert tento standard implementuje a dále rozšiřuje. Více viz [12] nebo [14].
3.1.2
Struktura systému Expert
Na obrázku 3.1 je znázorněna struktura systému Expert. Najdeme zde všechny typické součásti expertního systému tak, jak jsou popsány v podkapitole 2.2. V následujících odstavcích jsou tyto části popsány z hlediska toho, jak jsou v systému Expert implementovány.
Obrázek 3.1: Struktura systému Drools Expert. Zdroj: [10]
Produkční paměť Produkční paměť (nebo také báze znalostí) obsahuje pravidla, se kterými má systém pracovat. V Drools se pravidla zapisují pomocí tzv. Drools Rule Language (dále jen DRL) a jsou nejčastěji uložena v textových souborech s příponou .drl. Na obrázku 3.2 je příklad jednoduchého pravidla zapsaného v DRL. První řádek obsahuje klíčové slovo rule a za ním název pravidla, který je sice nepovinný, ale je vhodné ho vždy uvádět, protože to zvyšuje čitelnost pravidla. Následuje when část, která obsahuje
6
podmínky. Podmínky se zapisují pomocí DRL konstrukcí. Po podmínkách následují akce, které mohou obsahovat libovolný Java kód. Drools ovšem podporují i tzv. dialekty, které přidávají další možnosti zápisu. Více informací o dialektech se nachází v [10]. Celé pravidlo je ukončeno klíčovým slovem end. Podnikové pravidlo (business rule) [4] je pouze speciální případ pravidla. Jedná se o výrok, který definuje nebo omezuje nějaký aspekt podniku. Podniková pravidla obvykle obsahují akce, jež ovlivňují chování podnikových systémů. rule ‘‘Je osoba dospělá?’’ when Person (age >= 18) // podmínka then System.out.println(‘‘Osoba je dospělá’’) // akce end Obrázek 3.2: Příklad zápisu jednoduchého pravidla v Drools
Pracovní paměť Fakty jsou v Drools nejčastěji reprezentovány jako klasické Java objekty (Plain Old Java Object, POJO). Další možností je fakty deklarovat přímo spolu s pravidly. Na obrázku 3.3 je ukázka deklarace faktu. Na prvním řádku se nachází klíčové slovo declare, které říká, že se jedná o deklaraci faktu. Za ním je na stejném řádku uveden název faktu. Další řádky obsahují atributy, které daný fakt obsahuje. Stejně jako u pravidla je deklarace faktu zakončena klíčovým slovem end. declare Address street: String streetNumber : int city : String end Obrázek 3.3: Příklad deklarace faktu Drools Expert pracuje s pojmem relace (session), což je vlastně pracovní paměť. Je možné vytvořit několik relací souběžně (např. každou v jiném vláknu), a tak zajistit, že fakty vkládané do jednotlivých relací se vzájemně neovlivní. Relace je vytvářena z báze znalostí, jsou do ní vkládány fakty a poté nad ní aktivována pravidla. Expert rozlišuje dva typy relací: • Bezstavová relace (stateless session). Bezstavovou relaci lze přirovnat k zavolání funkce, které předáme parametry a ta vrátí nějaký výsledek. Tato relace není schopna si uchovat stav mezi jednotlivými aktivacemi pravidel. Používá se např. k validaci, výpočtům nebo k filtrování a směrování. • Stavová relace (stateful session). Stavová relace má delší životnost a umožňuje iterativní změny v průběhu času. Na rozdíl od bezstavové relace je možné vkládat fakty 7
postupně a pravidla lze také aktivovat opakovaně. Používá se např. k monitorování, diagnostice nebo v oblasti logistiky. Usuzovací podsystém Usuzovací podsystém (inference engine) je jádrem BRE. Pro usuzování se obecně používají dvě metody, dopředné řetězení (forward chaining) a zpětné řetězení (backward chaining). Systémy, které implementují obě metody, se nazývají hybridní systémy. Expert umožňuje použití obou těchto metod. Dopředné řetězení. Dopředné řetězení je tzv. řízeno daty (data-driven). Do pracovní paměti vkládáme fakty, což způsobí, že jedno či více pravidel jsou naplánovány pro aktivaci. Takto aktivovaná pravidla provádějí změny v pracovní paměti, což opět způsobí aktivaci dalších pravidel. Tento proces se opakuje, dokud existují pravidla, která lze aktivovat. Výsledek tohoto procesu je úsudek (conclusion). Zpětné řetězení. Zpětné řetězení je tzv. řízeno cílem (goal-driven), což je opak výše zmíněnéno řízení daty. Začíná se s úsudkem, který se snažíme uspokojit. Pokud tento uspokojit nelze, rozdělíme ho na podúlohy, které se snažíme uspokojit. Takto pokračujeme do té doby než je původní úsudek dokázán nebo už nejsou k dispozici žádné podúlohy. Např. programovací jazyk Prolog [19] využívá zpětného řetězení. Rozpoznávání vzorů. Rozpoznávání vzorů (pattern matching) se stará o tzv. navázání (matching) pravidel na nové nebo stávající fakty. Existuje několik algoritmů, které lze pro rozpoznávání vzorů použít, např. Linear, Rete či Leaps algoritmus. Expert implementuje Rete algoritmus [7] a rozšiřuje ho o nové funkce, spojené s objektově orientovanými systémy. Této rozšířené implementaci se říká ReteOO. Agenda Agenda je součástí usuzovacího podsystému. Jsou do ní vkládána pravidla, která mají splněné podmínky a je tedy možné je aktivovat. Při řešení konfliktů se v Drools nejčastěji používá strategie význačnosti (salience). Význačnost (nebo také priorita) je vlastnost pravidla. Pravidlo, které má vyšší význačnost (vyšší číslo) bude aktivováno dříve. Jestliže mají pravidla význačnost stejnou, pořadí spuštění je libovolné. Kromě význačnosti podporuje Expert také další možnosti pro řešení konfliktů. Jedná se např. o rule-flow skupiny nebo skupiny aktivací (activation groups). Více viz [10].
3.1.3
Vlastnosti pravidly řízeného programování
Při vytváření aplikací, které využívají BRE a tedy pravidly řízeného programování, narazíme na několik typických vlastností s tímto typem programování spojených [10]: Deklarativní programování. Pravidla umožňují vyjádřit co udělat“, ne jak to ” ” udělat“. Hlavní výhodou tohoto je, že pomocí pravidel lze jednoduše vyjádřit řešení složitých problémů a poté tato řešení ověřit. Pravidla jsou také mnohem čitelnější než kód. Oddělení aplikační logiky a dat. Data jsou v doménových objektech, logika aplikace je v pravidlech. Toto rozdělení porušuje OO princip zapouzdření, což může být výhoda i nevýhoda – záleží na úhlu pohledu. Výsledkem je, že logika může být v budoucnu jednoduše pozměněna. Centralizace znalostí. Vytvářením pravidel, která jsou uložena v repozitáři, vzniká centrální báze znalostí. Znalosti je možné jednoduše spravovat a upravovat, protože se nachází pouze na jednom místě. 8
Rychlost a škálovatelnost. Rete algoritmus, Leaps algoritmus a jejich nástupci, jako např. ReteOO, umožňují velmi efektivně provádět rozpoznávání vzorů, což je klíčové při vyhledávání pravidel, která budou aktivována.
3.2
Drools Fusion
V moderních systémech a aplikacích se nachází obvykle mnoho zdrojů událostí. Pojem událost (event) sám o sobě bývá často přetížen a využíván pro označení několika rozdílných věcí, v závislosti na kontextu, kde je použit. V této práci se pod pojmem událost bude rozumět záznam o významné změně stavu v aplikační doméně [11]. Těchto událostí je typicky velké množství a často vzniká potřeba je, na základě určitých pravidel, účinně a rychle filtrovat a dále zpracovávat. Fusion rozšiřuje možnosti systému Expert a do platformy Drools přidává právě funkcionalitu spojenou se zpracováním událostí.
3.2.1
Komplexní zpracování událostí
I přes několik pokusů o vytvoření definice pojmu komplexní zpracování událostí (Complex Event Processing, CEP) není aktuálně žádná z těchto definic široce přijata. V této práci se pod pojmem CEP bude rozumět koncept, který se zabývá otázkou zpracování rozmanitých událostí s cílem identifikovat významné události v rámci velké skupiny událostí (event cloud) [15]. Fusion přináší do Drools podporu pro CEP. Podpora pro CEP vyžaduje více než pouhé porozumění tomu, co událost je. Scénáře, ve kterých nachází CEP uplatnění, sdílejí několik společných charakteristik [11]: • Obvykle je nutné zpracovávat obrovský objem událostí, ale pouze velmi malá část z nich jsou ty, které nás zajímají. • Události bývají neměnné (immutable), protože se jedná o záznamy o změně stavu (změna proběhla v minulosti). • Obvykle existují silné časové vztahy mezi souvisejícími událostmi. • Jednotlivé události obvykle nejsou důležité. Systém se zajímá o skupiny souvisejících událostí a jejich vztahy. • Po systému se vyžaduje kompozice a agregace událostí. Na základě těchto obecných vlastností definuje Drools Fusion množinu cílů, kterých musí být dosaženo za účelem plné podpory CEP [11]: • Detekce, agregace a kompozice událostí. • Podpora zpracování proudů (streams) a shluků (clouds) událostí. • Podpora pro časová omezení za účelem modelování časových závislostí mezi událostmi. • Podpora pro posuvná okna (sliding windows) významných událostí. • Podpora pro (re)aktivaci pravidel. Popis těchto vlastností je nad rámec této práce. Podrobnější informace lze nalézt v [11].
9
Kapitola 4
Testování výkonu aplikací 4.1
Výkon aplikace a jak ho měřit
Definovat obecně pojem výkon aplikace nemusí být vůbec jednoduché. V jednom případě to může znamenat rychlost odezvy systému, v jiném počet událostí, které je systém schopen zpracovat za jednotku času, nebo také obojí dohromady. Záleží na kontextu, kde je tento pojem použit. Dle [16] to vše směřuje k tomu, že z pohledu koncového uživatele lze za výkonnou aplikaci považovat takovou aplikaci, která ho nezdržuje, když s ní pracuje. Aplikace se špatným výkonem obvykle nedodává potřebný přínos, který se od ní očekával. Uživatelé jsou často znechuceni, jestliže mají s takovou aplikací pracovat a jejich produktivita spíše klesá než stoupá. V případě aplikace, která není určena přímo pro koncové uživatele, ale např. jako zdroj informací pro další systémy, musí být tato aplikace schopna včas produkovat požadované výsledky, aby mohla být považována za výkonnou.
4.1.1
Jak výkon měřit?
Při měření výkonu je nutné vzít v úvahu několik klíčových ukazatelů. Tyto ukazatele lze rozdělit do dvou skupin [16]: orientované na službu (service-oriented) a orientované na účinnost (efficiency-oriented). Mezi ukazatele orientované na službu patří dostupnost (availability) a doba odezvy (response time); tyto měří, jak dobře (nebo špatně) aplikace poskytuje služby koncovým uživatelům. Ukazatele orientované na účinnost jsou propustnost (throughput) a vytíženost (utilization); tyto měří jak dobře (nebo špatně) aplikace využívá přidělených zdrojů. Dostupnost Množství času, kdy je aplikace dostupná pro systémy, které od ní získávají informace. Dostupnost se zpravidla měří v procentech jako poměr mezi časem, kdy byla aplikace dostupná, a časem, který uplynul od uvedení aplikace do provozu. Cílem je samozřejmě mít dostupnost co nejvyšší, ovšem dosažení 100% hranice není ve většině případů účelné. Prostředky vynaložené k zajištění takto vysoké dostupnosti jsou výrazně vyšší než případné ztráty v případě, že je aplikace na chvíli nedostupná. U velmi spolehlivých aplikací bývá obvykle více než 99,9 % [17].
10
Doba odezvy Čas, který aplikace potřebuje na reakci na požadavek uživatele nebo jiného systému. Společně s dostupností se jedná o nejdůležitější ukazatele z pohledu koncového uživatele. Z hlediska testování výkonu nás obvykle zajímá doba odezvy systému (system response time), což je doba mezi odesláním žádosti o odpověď (např. zavoláním výpočetní metody) a přijetím odpovědi (vrácením výsledku). Do této doby se také počítá např. zpoždění sítě. Cílem je dobu odezvy co nejvíce minimalizovat. Propustnost Četnost, s níž se objevují události související s aplikací. Např. počet zpracovaných událostí za jednotku času. Cílem každé aplikace je samozřejmě mít co nejvyšší propustnost. Vytíženost Procentuálně vyjádřený poměr teoretické kapacity a aktuálně využité kapacity zdroje. Příkladem je vytížení síťového pásma aplikací nebo spotřeba paměti na serveru. Monitorováním vytíženosti lze objevit tzv. úzké místo systému (bottleneck). Jedná se o část systému, která limituje výkon systému jako celku. Např. jestliže je paměť zcela zaplněná, ale vytížení procesoru se pohybuje v jednotkách procent, je nutné buď zvýšit kapacitu operační paměti na serveru, nebo aplikaci optimalizovat tak, aby spotřebovávala méně paměti. Proč je špatný výkon aplikací tak běžný? I přesto, že pro konkrétní aplikace lze výkon poměrně dobře definovat, mnoho z těchto aplikací se prezentuje velmi špatným výkonem. V [16] je uvedeno několik důvodů, proč tomu tak je: • výkonu není věnována dostatečná pozornost při návrhu aplikace, • testování výkonu se provádí na poslední chvíli, • podcenění počtu uživatelů, kteří budou aplikaci využívat, • nedostatečné používání automatizovaných testovacích nástrojů.
4.1.2
Typy výkonnostních testů
I přesto, že jsou následující pojmy obecně známé, často dochází k záměně jejich významu, a proto je zde uveden krátký popis každého typu testu [16, 20]. Základní test (baseline test) Test se spustí na nezatíženém systému a výsledek lze poté považovat za nejlepší, kterého lze vůbec dosáhnout. Změřená hodnota může být použita k určení výkonnostního poklesu v závislosti na vzrůstajícím zatížení aplikace. Zátěžový test (load test) Při zátěžovém testu se aplikace zatíží na požadovanou úroveň (např. určité množství zároveň přihlášených uživatelů) a poté se sleduje, zda a jak je aplikace schopna zpracovávat požadavky pod touto zátěží. 11
Stresový test (stress test) Stresový test slouží k nalezení horních limitů aplikace. Je generována čím dál větší zátěž tak dlouho, než aplikace odmítne komunikovat nebo doba odezvy přesáhne definovanou mez. Údaje se průběžně zaznamenávají a poté z nich lze určit, při jaké maximální zátěži je aplikace ještě schopna korektně pracovat. Dlouhodobý test (soak test) Dlouhodobým testem se zjišťuje chování aplikace pod dlouhotrvající zátěží. Tento typ testu umožňuje odhalit problémy, které se při zátěžových a stresových testech projevit nemusí. V případě kritických aplikací, jako např. řízení letového provozu, může test probíhat i několik měsíců [20].
4.2
Proces testování výkonu
Tato podkapitola popisuje obecný proces, kterým je vhodné se řídit, pokud má být testování výkonu provedeno správně. Celý proces je rozdělen do několika fází. Následující odstavce obsahují základní informace o tom, co je nutné v každé fázi udělat a jaké jsou její cíle. Podrobnější informace o celém procesu lze nalézt v [16], [2] nebo [9].
4.2.1
Určení požadavků na výkon
Před samotným návrhem, implementací a spouštěním testů je vhodné identifikovat, vyhodnotit a sepsat požadavky, které musí aplikace splňovat z hlediska výkonu. Např. kolik uživatelů musí být aplikace schopna paralelně obsloužit, jaká je maximální doba odezvy ve špičce aj. Bez těchto informací se jen velice těžko určuje, zda aplikace opravdu splňuje očekávané cíle, protože tyto cíle nejsou nikde definovány. V [2] autor uvádí, že požadavky na výkon by měly obsahovat alespoň následující: • Měřitelná hodnota doby odezvy (např. počet sekund). • Popis toho, které úlohy bude systém provádět, jestliže má být dosaženo požadované odezvy. • Procento případů, v nichž musí být požadovaná doba odezvy dosažena. • Konfigurace systému, ke kterému se doba odezvy vztahuje. Cílem je obvykle vytvořit dokument, který obsahuje tyto požadavky. Po skončení testovaní je možné, s využitím informací v tomto dokumentu, vyhodnotit, zda aplikace pracuje tak, jak se očekává, nebo zda je nutné aplikaci opravit z důvodu nedostatečného výkonu.
4.2.2
Analýza a návrh testů
Jedním z úkolů analýzy je identifikovat ty části aplikace, které mají být testovány. Jestliže nejsou tyto části zmámy, není možné navrhnout vhodné testy, a testování není možné provést. Dále je nutné určit metriky, které budou v průběhu testů zaznamenávány. Na základě těchto metrik lze po skončení testování určit, zda aplikace dosahuje požadovaného výkonu.
12
Návrh testů Cílem návrhu je identifikovat klíčové scénáře, ve kterých bude aplikace využívána, a podle těchto scénářů navrhnout transakce a testy. Transakce komunikuje přímo s testovaným systémem, zapouzdřuje tedy určitou posloupnost událostí a simuluje tak aktivitu uživatele. Test se poté skládá z jedné či více transakcí, řídí jejich spouštění a sbírá výsledky. Kritická je kvalita a množstvím testovacích dat pro jednotlivé testy. Bez nadsázky lze říci, že úspěch výkonnostního testu závisí na kvalitě a kvantitě testovacích dat. V [16] se mluví o třech typech testovacích dat: • vstupní data (vstupní data pro transakce), • cílová data (reprezentují stav aplikace), • data v době běhu programu (runtime data), což jsou např. data vrácená aplikací v odpovědi. Po skončení návrhu by mělo být jasné, jaké testy budou spuštěny, s jakými testovacími daty, co který test vlastně testuje (jakou konkrétní funkcionalitu) a jaké jsou předpokládané výsledky (např. test postupně zvyšuje objem zpracovávaných dat, proto se předpokládá, že s přibývajícím množstvím dat se bude zvyšovat také odezva systému). Testovací prostředí Testovací prostředí by mělo být v ideálním případě stejné jako to produkční. U rozsáhlých aplikací toho lze jen stěží dosáhnout, ať už z finančních, časových či jiných důvodů. Je ovšem vhodné se cílovému prostředí co nejvíce přiblížit např. počtem aplikačních vrstev, velikostí aplikačních databází atd. Toto ovšem platí pouze v případě, že před samotným testováním je známo, na jaké konfiguraci aplikace poběží v produkčním prostředí. Jestliže se testuje aplikace (či framework), která není určena koncovým uživatelům, ale např. vývojářům, kteří nad ní teprve staví výslednou aplikaci, je velmi obtížné určit, na jakém hardware/software tato aplikace poběží a proto lze jen stěží dopředu určit konkrétní požadavky na výkon. V případě těchto aplikací je proto vhodné se zaměřit např. na rozdíl ve výkonu odlišných verzí, čímž lze odhalit výkonnostní regresi nebo naopak zlepšení. Obecně lze požadavky na testovací prostředí rozdělit na hardwarovou, softwarovou a komunikační část. Hardwarová část obsahuje konfigurace a počet serverů. V případě části softwarové se jedná o verze nástrojů/aplikací, které budou při testování použity. V případě, že je aplikace nasazena na více fyzických strojích, je také nutné určit komunikační požadavky tak, aby odpovídaly produkčnímu nasazení. Opakované testy je nutné spouštět na stejné, nebo alespoň velmi podobné konfiguraci hardware/software, jako testy předchozí, aby bylo možné dosažené výsledky porovnávat.
4.2.3
Implementace a spuštění testů
Implementace transakcí a testů se odvíjí především od návrhu (viz podkapitola 4.2.2). Návrh každého z testů by měl popisovat, co se má vlastně testovat, jaká testovací data budou potřeba, o jakých typ testu se jedná atd. V případě výkonnostních testů je prakticky nezbytné, aby byly testy automatizovány. V případě manuálních testů není možné provést naprosto stejný test dvakrát, což je při určování, zda se výkon zlepšil či zhoršil, klíčové. Před samotným spuštěním testů je nutné
13
zkontrolovat, že je testovací prostředí připraveno a že všechny další požadavky, které jsou uvedeny v návrhu, jsou splněny. Po spuštění testů je nutné tyto testy monitorovat, ověřit, zda mohou přistupovat k testované aplikaci a v případě problémů testy zastavit, opravit chyby a opět testy spustit. Výstupem fáze spouštění testů jsou statistická data, např. o době trvání jednotlivých testů, době odezvy aplikace nebo spotřebě paměti, která musí být dále zpracována a analyzována, viz podkapitola 4.2.4.
4.2.4
Zpracování a analýza výsledků
Správná interpretace výsledků je nesmírně důležitá. Právě tato fáze určí, zda dosažené výsledky jsou ty, které byly očekávány. Pokud tomu tak není, je důležité mít k dispozici veškeré nezbytné informace k tomu, aby bylo možné identifikovat, kdy došlo k problémům a proč k nim došlo. Analýzu výsledků lze provádět v průběhu testu (dynamic analysis) a/nebo po skončení běhu testu (post-mortem analysis). • Analýza v průběhu testu. V podstatě se jedná o průběžné monitorování. Jestliže dojde k chybě, je nutné tuto chybu odstranit a testy opakovat. Nevýhodou použití této metody je zátěž, která je generována monitorovacími systémy. • Analýza po skončení testu. Veškeré informace nasbírané během testu by měly být přístupné po jeho dokončení. To, jak jsou data uložena, není zvlášť důležité, pouze je nutné zajistit, aby nedošlo k jejich ztrátě. Nevýhodou této metody je náročnost zpracování výsledků. Těch je obvykle velké množství a je nutné vybrat jen ty relevantní a důležité. Výhodou používání automatizovaných testů je v tomto případě možnost výstup z testu porovnat s předešlými běhy testů a zjistit tak, zda došlo k nějaké změně.
14
Kapitola 5
Testování výkonu Drools Expert a Drools Fusion Testování bylo zaměřeno především na možnost odhalení výkonnostní regrese mezi různými verzemi systémů Expert a Fusion. Práce se zabývá porovnáním verzí BRMS 5.1.0 a vývojové verze Drools 5.2.0 M2. Pojem BRMS (úplným názvem JBoss Enterprise BRMS) se objevuje v této práci poprvé, proto je nutné ho objasnit. BRMS je produktizovaná verze Drools. Vychází ze stejného zdrojového kódu, přičemž produktizovaná verze obvykle obsahuje další malé změny. Konkrétně BRMS 5.1.0 vychází z Drools 5.1.1. Jelikož se nejedná o aplikace určené pro koncové uživatele, některé kroky obecného procesu testování výkonu (viz podkapitola 4.2) nebyly prováděny. Jedná se např. o dokument s požadavky na výkon tak, jak se o něm zmiňuje podkapitola 4.2.1.
5.1
Analýza, návrh testů a testovací prostředí
Z hlediska výkonu obou systémů jsou hlavními metrikami, které je nutné zaznamenávat, doba potřebná k vložení faktů (událostí) do stavové/bezstavové relace a poté doba potřebná k aktivaci pravidel. V případě stavové relace lze změřit obě tyto hodnoty odděleně. U bezstavové relace lze ovšem změřit pouze celkovou dobu, protože obě tyto operace jsou prováděny zároveň (v rámci volání jedné metody). V případě systému Fusion je dalším významným ukazatelem propustnost, tj. kolik událostí je schopen systém zpracovat za jednotku času. Tento údaj lze vypočítat z doby potřebné pro aktivaci pravidel a z počtu zpracovávaných událostí. Dalším důležitým ukazatelem je spotřeba paměti. Je nutné monitorovat velikost alokované paměti, aby bylo možné odhalit případné změny v různých verzích. U obou systémů se nabízelo testovat jak stavovou, tak bezstavovou relaci. V systému Expert se typicky používají obě tyto relace, proto je vhodné je zahrnout do testů. Ovšem v případě modulu Fusion má smysl testovat pouze stavovou relaci, protože události jsou typicky vkládány v průběhu času (mají časovou známku) a ne najednou v jednom časovém okamžiku tak, jak tomu může být u faktů v případě systému Expert. Jako implementační jazyk byla zvolena Java. Jelikož celý projekt Drools je psán v Javě, tato volba se přímo nabízela. Jako doménový model byl zvolen model bankovního prostředí. Hlavním důvodem byl dostatek informací o této doméně a také fakt, že je často využívána v literatuře a dalších zdrojích. Implementovat celou bankovní doménu by bylo ovšem zbytečné a nereálné. Testy
15
pracují pouze se čtyřmi druhy objektů (jedná se o mírně upravený model použitý v [1]): • zákazník (třída Customer) - zákazník banky, • adresa (třída Address) - adresa zákazníka, • účet (třída Account) - bankovní účet, • transakce (třída Transaction) - transakce mezi dvěma účty. Fakty (události) je nutné generovat s určitým stupněm náhodnosti. Důležitým faktorem je také počet faktů, které budou navázány na pravidla a počet ostatních faktů, tj. těch, které na pravidla navázány nebudou. V případě systému Expert je 15-30 % faktů navázáno na pravidla. Událostí je v případě systému Fusion navázáno výrazně méně. Důvodem je snaha o zachycení reálného případu užití. V produkčních systémech je typicky na pravidla navázáno velmi malé množství z celkového počtu událostí. Jedná se pouze o cca 2 % událostí1 .
5.1.1
Návrh transakcí a testů
Z důvodu jednoduššího nalezení zdroje případné výkonnostní regrese, byly testy navrženy pro jednotlivé funkce (skupiny funkcí) každého ze systémů, a tyto základní testy poté sloužily jako základ pro několik testů komplexních. Funkce systému Expert byly rozděleny do následujících skupin. Pro každou skupinu byla poté vytvořena jedna transakce: • základní operátory - <, <=, >, >=, ==, ! =, &&, ||, • pokročilé operátory - contains, not contains, memberOf, not memberOf, matches, not matches, • pokročilé operátory 2 - složená hodnota (operátor in), přistup k vnořeným prvkům (např. customer.accounts[0]), podmíněné prvky (infix, prefix) and, or, • pokročilé operátory 3 - not, exists, forall, eval, inline eval, • pokročilé operátory 4 - from, collect, accumulate (avg, min, max). Pro systém Fusion byly funkce rozděleny do následujících skupin: • operátory after a before, • operátory coincides, during a includes, • operátory finishes a finishedby, • operátory meets a metby, • operátory overlaps a overlappedby, • operátory starts a startedby. 1
Údaje byly poskytnuty vývojářem modulu Fusion s tím, že se jedná o typické hodnoty v produkčních systémech.
16
Nejedná se o vyčerpávající seznam všech operátorů, která je možné použít. Byly vybrány jen ty nejznámější a nejpoužívanější. Pro každou z těchto transakcí byl vytvořen samostatný test. Dále byly vytvořeny komplexní testy, které obsahují zároveň více transakcí. Měření spotřeby paměti obstarává test vytvořený speciálně k tomuto účelu. Postupně spouští několik desítek transakcí a po každé provedené transakci měří velikost obsazené paměti. Všechny transakce musí být spuštěny nad stejnou relací, aby bylo možné odhalit případné nežádané navýšení paměti při opakovaném použití jedné instance relace. Struktura testů Na obrázku 5.1 se nachází zjednodušený vývojový diagram, který znázorňuje průběh jednoho testu. Základem je jedna nebo více transakcí, které jsou v průběhu testu spouštěny. Tyto transakce jsou spouštěny v jedné či více iteracích. Výsledky testu a jednotlivých transakcí jsou ukládány do souborů na disku.
Obrázek 5.1: Zjednodušený vývojový diagram průběhu testu. Obrázek 5.2 ukazuje zjednodušený diagram tříd (obsahuje pouze nejdůležitější třídy), které byly pro účely testování navrženy. Společným předkem všech testů je abstraktní třída DroolsPerfTest, která obsahuje atributy a metody společné pro Expert i Fusion testy. Test obsahuje seznam transakcí (viz dále), které mají být v rámci něho spuštěny. Jelikož se testy pro Expert a Fusion liší, vznikly abstraktní třídy DroolsExpertPerfTest a DroolsFusionPerfTest. Tyto třídy reprezentují předchůdce všech konkrétních Expert nebo Fusion testů. O ukládání výsledků se stará třída ResultsWriter (viz níže). Třída DroolsPerfTransaction obsahuje implementaci společnou pro Expert i Fusion transakce. Z této třídy dále dědí dvě abstraktní třídy, které reprezentují Expert transakci 17
a Fusion transakci. Jedná se o třídy ExpertPerfTransaction a FusionPerfTransaction. Hlavním důvodem pro vznik dvou různých tříd je rozdílné spouštění Expert/Fusion transakcí. V případě systému Expert se jedná o vložení faktů do relace a poté zavolání metody fireAllRules(), která zajistí aktivaci pravidel. Fusion transakce řeší vkládání událostí (faktů) pomocí tzv. event senderů. Tyto slouží k zasílaní (vkládání) událostí do relace. Každý z nich musí implementovat rozhraní EventSender, které definuje základní metody pro ovládání.
Obrázek 5.2: Zjednodušený diagram tříd používaných při testování.
Sběr a ukládání výsledků Jako nejjednodušší řešení se jevilo výsledky jednotlivých iterací postupně ukládat do kolekce v paměti, a po skončení testu obsah této kolekce zapsat do souboru na disku. Problém ovšem nastává v případě, že se provádí mnoho opakování testu (10000 a víc). Výsledky zabírají v paměti značnou část a ovlivňují tak měření spotřeby paměti. Od tohoto jednoduchého řešení bylo nakonec upuštěno a bylo nutné přijít s řešením, které výsledky ukládá průběžně. K tomuto účelu vznikla třída ResultsWriter. Jedná se o třídu, která implementuje rozhraní java.io.Runnable, a tudíž umožňuje běh v samostatném vláknu. Výsledky, které jsou zapisovány do souborů jsou reprezentovány jako třídy, které implementují rozhraní DataResult. ResultsWriter je spuštěn před první iterací testu. Po skončení každé 18
iterace je výsledek předán ResultWriteru a ten ho zapíše na disk při příštím zápisovém cyklu. K předání výsledků slouží metoda write(File file, DataResult result), kde parametr file určuje, do jakého souboru má být výsledek zapsán a result je samotný výsledek. Zápis výsledků probíhá jednou za určitý časový interval. Data jsou v souborech uložena ve formátu CSV2 (Comma Separated Values – hodnoty oddělené čárkami). Hlavními výhodami tohoto formátu je jeho rozšířenost, dobrá podpora ze strany různých nástrojů a fakt, že se jedná o textový formát. Nevýhodou může být větší velikost výsledného souboru v porovnání s binárním formátem. Tato nevýhoda byla zanedbána z důvodu velké kapacity moderních pevných disků a malé ceny za 1GB.
5.1.2
Testovací prostředí
Po hardwarové stránce nebyly na testovací prostředí kladeny velké požadavky. V principu lze testy spustit na běžném stroji, na kterém je v dispozici virtualní stroj Javy. K dosažení relevantních výsledků je vhodné testovat na stroji s více procesory (jádry). Systémy Expert i Fusion pracují v jediném vláknu a využijí tak pouze jeden procesor. Ostatní procesory tak mohou být použity pomocnými vlákny, která se starají např. o posílání událostí nebo zapisování výsledků testů do souborů na disku. Hardwarová konfigurace strojů, na kterých bylo testování prováděno je následující: 2 krát procesor AMD Opteron 2356, operační paměť 10GB. Uvedeny jsou pouze hodnoty, které mají, nebo mohou mít, vliv na výsledky testů.
5.2
Implementace a spuštění testů
Implementace každého z testů probíhala v následujících krocích: 1. Implementace jedné nebo více transakcí (viz. dále) potřebných pro test. Jestliže již byla transakce vytvořena v rámci jiného testu, stačí ji pouze použít, není nutné ji znovu implementovat. 2. Vytvoření testu, který obsahuje vybrané transakce. Hlavní úlohou testu je dané transakce spouštět a sbírat jejich výsledky. Jádrem každého testu je jedna či více transakcí. Implementace každé z těchto transakcí probíhala v následujících krocích: 1. Vytvořit pravidla, se kterými bude transakce pracovat. Pravidla určují, která část systému bude transakcí pokryta. Typicky každá transakce obsahuje množinu pravidel, ve kterých jsou použity testované operátory. 2. Vygenerovat fakty nebo události. Fakty je nutné generovat alespoň částečně rozdílná. Jestliže se vygeneruje 1000 naprosto stejných faktů, nesimuluje to reálně použití daného systému. Implementace transakcí a testů představovala iterativní proces. Docházelo k tomu, že fakty nebyla dostatečně jednoznačné a při použití i malého počtu z nich se vytvořilo několik desítek tisíc aktivací v agendě, což je z hlediska reálného použití nesmyslné. Bylo proto nutné vygenerovat fakty tak, aby se opravdu navázaly jen na ta pravidla, na která mají, a tím se snížil celkový počet aktivací. 2
http://tools.ietf.org/html/rfc4180
19
Při psaní navržených testů se na e-mailové konferenci vývojářů Drools objevil příspěkterý poukazuje na výkonnostní regresi mezi verzemi Drools 5.2.0 M1 a 5.2.0 M2. Konkrétně se jedná o výrazné zpomalení při použití dialektu mvel ve verzi 5.2.0 M2. Jelikož se jedná o klíčovou funkcionalitu, byl pro ni vytvořen samostatný test. Za implementační zajímavost lze považovat volání metody System.gc(). Metoda sama nezaručuje volání GC, ale říká JVM, že pokud je to možné, měl by GC provést. Obecně je doporučeno tuto metodu vůbec nepoužívat a nechat výběr okamžiku pro odstranění nepotřebných objektů na JVM. Pozorováním bylo zjištěno, že v pravidelných intervalech dochází ke zvýšení doby trvání iterace testu. Ukázalo se, že to bylo způsobeno právě uvolňováním paměti. Z tohoto důvodu je před každou iterací volána zmíněna metoda. Výše zmíněná metoda System.gc() je také volána před každým měřením stavu paměti. Hodnoty získané tímto měřením, které v sobě obsahují i objekty, které jsou již nedostupné, ale GC ještě nebyl spuštěn a tudíž nebyly odstraněny, by pouze zkreslovaly výsledky. vek3 ,
Generování faktů (událostí) Generování faktů a událostí je prováděno velmi jednoduše, pouze za pomoci cyklů, ve kterých jsou do kolekce vkládány fakty. V případě faktů je tato kolekce je uložena jako seznam (java.util.List) objektů typu Object v serializované formě v binárním souboru. Událost s sebou musí nést také informaci, v jakém časovém okamžiku vznikla (a kdy má tedy být do stavové relace vložena). V kolekci jsou proto ukládány objekty typu EventRecord, kde každý tento záznam obsahuje referenci na konkrétní událost a časový údaj. Fakty i události jsou ukládány resp. načítány pomocí standardních (de)serializačních metod writeObject() resp. readObject(). Pro každou transakci bylo nutné vytvořit několik souborů, které se lišily počtem faktů, které jsou v nich uloženy. Spouštění testů Přeložení a spuštění testů zajišťuje nástroj Apache Ant4 . Ve světě Javy se jedná o standardní a velmi rozšířený nástroj pro sestavování programů. Počet pravidel, faktů a další parametry lze zadat pomocí tzv. vlastností (properties). Jelikož spouštění testů manuálně pro různý počet pravidel/faktů by bylo časové náročné, byl využit systém Hudson5 , který umožňuje tuto činnost automatizovat. Hudson je tzv. systém průběžné integrace (continuous integration system, CI system), který je často používán pro spouštění automatizovaných testů. Každý z testů lze spustit jak s rozdílným počtem pravidel, tak faktů. Tímto vzniká celá spouštěcí matice. Hudson je schopen tuto matici automaticky spustit, čímž vzniká ona časová úspora oproti manuálnímu spouštění. Testy byly spuštěny v prostředí 64bitového operačního systému Red Hat Enterprise Linux6 5 a v 64bitovém běhovém prostředí Javy od firmy Oracle (dříve Sun), verze 1.6.0. Jedná se o nejrozšířenější implementaci JVM, proto byl výběr jednoznačný. V budoucnosti by bylo ovšem vhodné spustit alespoň některé testy na jiné verzi JVM a ověřit, zda je výkon systémů Expert a Fusion na obou implementacích stejný.
3
http://permalink.gmane.org/gmane.comp.java.drools.devel/4763 http://ant.apache.org/ 5 http://www.hudson-ci.org 6 http://www.redhat.com/rhel/ 4
20
5.3
Analýza výsledků
Statistická data byla analyzována po dokončení testů (tj. post-mortem). Analýza v době běhu testů (tj. dynamic) nebyla prováděna, ale díky logům, které testy produkují, může být v budoucnu implementována.
5.3.1
Analýza po skončení testů
V této fázi přišlo na řadu vyhodnocování postupně nasbíraných výsledků testů. Z velkého množství dat bylo nutné vybrat vhodné a zajímavé výsledky. Následující podsekce obsahují analýzu výsledků převážně z hlediska porovnání výkonnosti obou verzí. Při vyhodnocování výsledků bylo nutné brát ohled na tzv. zahřívací čas (warm-up time). Jedná se o dobu potřebnou k ustálení výsledků jednotlivých běhů testů. Výsledky několika prvních iterací jsou typicky výrazně vyšší, než výsledky iterací dalších. Důvodem je provádění jednorázových operací (např. zavádění tříd do paměti a alokace datových struktur) v průběhu těchto úvodních běhů. Tento je možné vidět na obrázku 5.3, který bude blíže popsán později. Srovnání výkonu BRMS 5.1.0 a Drools 5.2.0 M2 Následující odstavce si kladou za cíl provést jednoduché srovnání výkonu mezi verzemi BRMS 5.1.0 a Drools 5.2.0 M2. V žádném případě se nejedná o komplexní a úplné srovnání, ale pouze o porovnání výsledků základních testů, které byly spuštěny. Expert Výsledky testů pro systém Expert jsou uvedeny v tabulce 5.1. Hodnoty, které nejsou v tabulce uvedeny, nebylo možné získat z důvodu funkčních chyb ve verzi Drools 5.2.0 M2. Údaje v tabulce představují průměrnou hodnotu z 300 běhů testu. První dva sloupce představují výsledky pro verzi BRMS 5.1.0. Hodnoty ve třetím a čtvrtém sloupci odpovídají výsledkům pro verzi Drools 5.2.0 M2. Při porovnání těchto výsledků je patrný výrazný rozdíl mezi zmíněnými verzemi. Testy spuštěné s verzí Drools 5.2.0 M2 trvají několikanásobně (až dvacetinásobně) delší dobu. Testy byly spuštěny opakovaně, ale výsledky byly vždy velmi podobné. Stejný trend vykazují i testy se 100 a 1000 fakty. Po krátkém hledání v chybách, které jsou v rámci Drools nahlášeny, byl nalezen záznam7 , který se zmiňuje o degradaci výkonu mezi verzemi 5.2.0 M1 a 5.2.0 M2. Popisovaná chyba může souviset s degradací výkonu, kterou lze pozorovat v tomto případě. Dle komentáře jednoho z vývojářů by měla být tato chyba opravena ve verzi 5.2.0 CR1. Za povšimnutí stojí také rozdíl mezi stavovou a bezstavovou relací. Bezstavová relace by měla být podle předpokladů rychlejší než stavová. Výsledky testů ovšem značí pravý opak. Ve většině případů je čas pro bezstavovou relaci vyšší než pro stavovou. Důvodem mohla být prostá záměna času pro stavovou a bezstavovou relaci. Toto se ovšem, při bližším zkoumání testů, nepotvrdilo a bylo proto nutné hledat chybu na jiném místě. Další možností bylo chybné měření času (čas se začal měřit příliš brzy nebo naopak bylo měření pozdě ukončeno), ale ani tato hypotéza se nepotvrdila. Chybu se bohužel nepodařilo objevit. Fusion Tabulka 5.2 obsahuje výsledky Fusion testů při použití 5000 událostí. Jsou uvedeny výsledky pro obě testované verze modulu Fusion. Řádky tabulky reprezentují jednot7
https://issues.jboss.org/browse/JBRULES-2982
21
test / doba trvání pro danou verzi základní operátory pokročilé operátory pokročilé operátory pokročilé operátory pokročilé operátory komplexní test 1 komplexní test 2
1 2 3 4
BRMS 5.1.0 [ms] stavová bezstavová 478.25 529.13 39.04 40.77 36.49 38.90 2968.48 3278.01 60.06 61.61 273.62 281.27 2501.17 2660.42
Drools 5.2.0 M2 [ms] stavová bezstavová 9045.50 9061.34 – – 3888.04 3806.33 66634.30 69157.50 – – – – – –
Tabulka 5.1: Výsledky Expert testů při použití 10000 faktů. livé testy a sloupce dobu trvání těchto testů při použití dané verze. Uvedené hodnoty byly vypočteny jako průměr z 1500 iterací testu. Obecně lze konstatovat, že testy s verzí Drools 5.2.0 M2 trvají delší dobu. Až na jednu výjimku se ovšem jedná o velmi malé rozdíly. Zmíněnou výjimkou je test na operátory coincides a during. V případě verze 5.2.0 M2 trvá tento test v průměru více než dvakrát déle oproti verzi BRMS 5.1.0. Další testy s nižším počtem událostí (1000 a 500) toto zpomalení potvrzují. Za povšimnutí také stojí test pro operátory after a before. Tento test trvá přibližně dvakrát až čtyřikrát déle než testy pro ostatní operátory. Rozdíl je patrný i ve výsledcích testů se 100, 500 a 1000 událostmi. Doba tohoto testu je pro obě verze stejná, nejedná se tudíž o regresi. Tuto skutečnost je nutné dále konzultovat s vývojáři. test / čas pro danou verzi operátory after, before operátory coincides, during operátory finishes, finishedby operátory meets, metby operátory overlaps, overlappedby operátory starts, startedby komplexní test 1 komplexní test 2
BRMS 5.1.0 [ms] 86.45 22.04 20.76 34.93 34.07 35.32 76.98 103.36
Drools 5.2.0 M2 [ms] 89.30 50.72 22.00 37.69 39.89 38.98 – 104.73
Tabulka 5.2: Výsledky Fusion testů při použití 5000 událostí.
Další testy Obrázek 5.3 ukazuje rozdíl mezi časem trvání mvel testu pro prvních 400 iterací při použití verze BRMS 5.1.0 a verze Drools 5.2.0 M2 pro 1000 faktů. Na vodorovné ose je vyneseno číslo iterace testu, hodnoty na svislé ose představují dobu trvání příslušné iterace testu. V levé části grafu je vidět výše zmiňovaný zahřívací čas. Porovnáním čáry v horní části grafu odpovídající verzi Drools 5.2.0 M2 a čáry ve spodní části grafu odpovídající verzi BRMS 5.1.0 lze určit, že pro 1000 faktů je zpomalení ve verzi Drools 5.2.0 M2 více než patnáctinásobné. Spotřeba paměti Při měření obsazené paměti nebylo cílem zjistit absolutní spotřebu, ale rozdíl ve spotřebě mezi jednotlivými verzemi. Hodnoty v následující tabulce a grafu tudíž nevyjadřují přesnou 22
Mvel test při použití 1000 faktů 600 500
čas [ms]
400 Drools 5.2.0 M2 300 200 100 BRMS 5.1.0 0
0
50
100
150
200
250
300
350
400
iterace #
Obrázek 5.3: Porovnání doby trvání mvel testu pro verze BRMS 5.1.0 a Drools 5.2.0 M2. spotřebu paměti daným modulem, je nutné do nich zahrnout také paměť alokovanou pro testy, transakce a další pomocné třídy. Lze ovšem porovnávat hodnoty pro jednotlivé verze, protože režie je stejná, a tudíž případné zvýšení/snížení by měl na svědomí testovaný modul. Tabulka 5.3 shrnuje údaje o velikosti obsazené paměti. Jedná se o průměrnou hodnotu ze 100 běhů testu. Jeden řádek představuje měření po daném počtu zpracovaných transakcí. Sloupce obsahují hodnoty pro konkrétní verzi systému Expert a typ relace. První dva sloupce představují hodnoty pro verzi BRMS 5.1.0, třetí a čtvrtý sloupec hodnoty pro verzi Drools 5.2.0 M2. Při porovnání hodnot je patrné, že spotřeba paměti je prakticky stejná pro obě testované verze. Rozdíl mezi stavovou a bezstavovou relací, z pohledu spotřeby paměti, je znázorněn na obrázku 5.4. Jedná se opět o průměrnou hodnotu ze 100 běhů testu. Svislá osa obsahuje údaj o obsazené paměti v MiB. Na vodorovné ose je číslo transakce, po jejímž dokončení byla hodnota změřena. S přibývajícím množstvím transakcí roste počet faktů, které určují stav relace, a proto v případě stavové relace roste spotřeba paměti. Bezstavová relace stav neudržuje, objekty mohou být po skončení výpočtu z paměti uvolněny, a proto je také spotřebovaná paměť v tomto případě konstantní. Oba tyto výsledky jsou očekávané. Porovnání spotřeby paměti pro systém Fusion není uvedeno z důvodu chyby ve verzi Drools 5.2.0 M2, která znemožňuje dokončení tohoto testu. transakcí / obsazená paměť po po po po
25. transakci 50. transakci 75. transakci 100. transakci
BRMS 5.1.0 [MiB] stavová bezstavová 46.60 25.00 110.06 24.30 214.42 24.90 359.81 24.56
Drools 5.2.0 M2 [MiB] stavová bezstavová 47.22 24.73 110.68 24.64 215.05 24.90 360.43 25.00
Tabulka 5.3: Spotřeba paměti po verze BRMS 5.1.0 a Drools 5.2.0 M2. 23
Spotřeba paměti při použití stavové a bezstavové relace v Drools 5.2.0 M2 400
stavová relace bezstavová relace
obsazená paměť [MiB]
350 300 250 200 150 100 50 0
0
10
20
30
40
50
60
70
80
90
100
transakce #
Obrázek 5.4: Porovnání spotřeby paměti při použití stavové a bezstavové relace.
24
Kapitola 6
Závěr Cílem práce bylo navrhnout a implementovat sadu výkonnostních testů pro systémy Drools Expert a Drools Fusion a prostředí pro sběr výsledků z těchto testů. Testy byly navržené s důrazem na možnost nalezení výkonnostní regrese mezi jednotlivými testovanými verzemi. K tomuto účelu vzniklo několik základních testů, které se zaměřují vždy na určitou skupinu funkcí. Testy byly spuštěny na dvou verzích zmíněných nástrojů a výsledky dále analyzovány. Tímto byly splněny všechny body zadání. V rámci analýzy výsledků bylo objeveno několik výkonnostních problémů ve verzi Drools 5.2.0 M2. Jedná se především o výrazné zpomalení při vyhodnocování pravidel napsaných pomocí mvel dialektu. Dalším vážným problémem je celková degradace výkonu systému Expert. Jednotlivé testy trvají několikrát déle v porovnání s verzí BRMS 5.1.0. Tato chyba je již ovšem nahlášena a v době odevzdávání práce pravděpodobně také už opravena. Při implementaci a spouštění testů bylo také objeveno několik funkčních chyb, které byly konzultovány s technickým vedoucím práce. Tyto chyby budou podrobeny dalšímu zkoumání a poté nahlášeny do systému, který slouží k evidenci chyb v nástrojích Drools. Práce sloužila jako pilotní projekt pro nalezení vhodných postupů při testování výkonu systémů Expert a Fusion. Testy vytvořené v průběhu práce budou s velkou pravděpodobností dále používány a rozšiřovány v rámci firmy Red Hat. Testy lze dále rozšiřovat hned několika způsoby. Je možné vytvořit netriviální generátor pravidel tak, aby mohly být testy spouštěny s proměnným počtem pravidel. Generátor by měl být dostatečně obecný, aby bylo možné generovat jakákoliv pravidla na základě určité šablony. Dále by bylo vhodné vytvořit množinu transakcí, které by reprezentovaly zjednodušený bankovní systém. Tyto transakce by sloužily jako základ testů zaměřených na použití pravidel v reálném systému. V neposlední řadě je také možné vytvořit výkonnostní testy pro další moduly platformy Drools (Guvnor, Planner nebo Flow).
25
Literatura [1] Bali, M.: Drools JBoss Rules 5.0. Packt Publishing, 2009, 301 s., iSBN 978-1-847195-64-7. [2] Bath, G.; McKay, J.: The Software Test Engineer’s Handbook. Rocky Nook, 2008, 397 s., iSBN 978-1-933-95224-6. [3] Browne, P.: JBoss Drools Business Rules. Packt Publishing, 2009, 285 s., iSBN 978-1-847196-06-4. [4] Business Rules Group: What is Business Rule? [online]. Dostupné na URL: http://www.businessrulesgroup.org/defnbrg.shtml, [cit. 2011-01-21]. [5] Čecho, J.: Zpřístupnění funkcí CLIPS z jazyka Ruby, bakalářská práce. FIT VUT v Brně, 2010. [6] Eckel, B.: Thinking in Java. Paerson Education, 2000, iSBN 978-0-130-27363-5. [7] Giarratano, J. C.; Riley, G. D.: Expert Systems: Principles and programming. Thomson Learning, Inc, 2005, iSBN 0-534-38447-1. [8] Jendrock, E.; Evans, I.; Gollapudi, D.; aj.: The Java EE 6 Tutorial: Basic Concepts. Prentice Hall, 2010, 600 s., iSBN 978-0-137-08185-1. [9] Kolektiv autorů: Performance Testing Guidance for Web Applications [online]. Dostupné na URL: http://msdn.microsoft.com/en-us/library/bb924376.aspx, 2007-07 [cit. 2010-01-03]. [10] Kolektiv autorů: Drools Expert User Guide [online]. Dostupné na URL: http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-expert/ html/index.html, [cit. 2010-12-12]. [11] Kolektiv autorů: Drools Fusion User Guide [online]. Dostupné na URL: http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-fusion/ html/index.html, [cit. 2010-12-12]. [12] Kolektiv autorů: JSR94 Java Rule Engine API [online]. Dostupné na URL: http://jcp.org/aboutJava/communityprocess/final/jsr094/index.html, [cit. 2010-12-15]. [13] Lindholm, T.; Yellin, F.: Java Virtual Machine Specification. Prentice Hall, 1999, iSBN 978-0-201-43294-7.
26
[14] Mahmoud, Q. H.: Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications [online]. Dostupné na URL: http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html, updated 2005-07-25 [cit. 2010-12-12]. [15] Mollenkopf, A.; Tirelli, E.: Applying Drools Fusion Complex Event Processing (CEP) for Real-Time Intelligence [online]. Dostupné na URL: http://www.redhat.com/f/pdf/jbw/amollenkopf_430_applying_drools.pdf, [cit. 2011-01-21]. [16] Molyneaux, I.: The Art of Application Performance Testing. O’Reilly, 2009, 145 s., iSBN 978-0-596-52066-3. [17] Piedad, F.; Hawkins, M. W.: High Availability: Design, Techniques and Processes. Prentice Hall, 2000, 288 s., iSBN 978-0-130-96288-1. [18] Shortliffe, E. H.: Computer-baded Medical Consultations: MYCIN. Elseview Science Ltd, 1976, iSBN 0-444-00179-4. [19] Sterling, L.; Shapiro, E.: The Art of Prolog. The MIT Press, 1994, iSBN 978-0-262-19338-2. [20] WWW stránky: Types of performance tests [online]. Dostupné na URL: http://www.loadtest.com.au/types_of_tests.htm, [cit. 2010-01-03].
27
