Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Bakalářská práce

Nástroj pro optimalizaci výkonu Rails aplikací Ondřej Ezr

Vedoucí práce: Tomáš Bartoň

1. května 2015

Poděkování Děkuji zejména svému vedoucímu, Tomáši Bartoňovi, za nezměrnou trpělivost a cenné rady. Rodičům, za úžasnou podporu psychickou i materiální jak při psaní této práce, tak v průběhu celého studia. Dále bych chtěl poděkovat Marku Plaštiakovi, za pomoc s udržením zdravého rozumu, když se věci všedního života snažili dostat v prioritním žebříčku před psaní této práce. Dominiku Dragounovi bych rád poděkoval za diskuze při pauzách, které mi pomohli udržet směr mých myšlenek.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou, a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla, a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.

V Praze dne 1. května 2015

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

České vysoké učení technické v Praze Fakulta informačních technologií © 2015 Ondřej Ezr. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Ezr, Ondřej. Nástroj pro optimalizaci výkonu Rails aplikací. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2015.

Abstrakt V několika větách shrňte obsah a přínos této práce v češtině. Po přečtení abstraktu by se čtenář měl mít čtenář dost informací pro rozhodnutí, zda chce Vaši práci číst. Klíčová slova rails, výkon, monitoring

Abstract Sem doplňte ekvivalent abstraktu Vaší práce v angličtině. Keywords rails, performance, monitoring

ix

Obsah Úvod Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2

1 Současný stav 1.1 Problémy . . . . 1.2 Výkon aplikace 1.3 Existující řešení 1.4 Srovnání . . . .

3 3 3 4 6

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Požadavky

7

3 Realizace 3.1 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Navržené řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 11

4 Použití 4.1 Konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15

Závěr

17

Literatura

19

A Seznam použitých zkratek

21

B Obsah přiloženého CD

23

xi

Seznam obrázků 1.1 1.2 1.3

Peek bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peek bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Peek bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 6 6

4.1

Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

xiii

Seznam tabulek 1.1

Srovnání řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv

6

Úvod Web je dnes masivně se rozvíjející médium, přenášející stále více informací a poskytující stále více služeb. Poptávka po těchto službách rapidně roste a webové aplikace se rozšiřují do nejrůznějších odvětví, ve kterých jsme si využití webu neuměli před 20ti lety ani představit. Webové aplikace začínají být čím dál rozšířenější, začínají převládat nad aplikacemi lokálními a to ve všech odvětvích. Všechny aplikace se přesouvají na internet zejména kvůli snadné přenositelnosti, sdílení dat, propojení dat uživatelů vzájemně a dalším nesporným výhodám internetu. Web je dnes zkátka opravdu všude kolem nás. Vzniká velké množství webových aplikací. A jelikož není dostatek profesionálních vývojářů, velké množství z nich pochází z rukou neprofesionálních vývojářů. Avšak tyto aplikace mají jeden zásadní nešvar a to předpokládat, že pokud jsou na serveru, nemusí se příliš ohlížet na výkon. Proto větší a rozšířenější aplikace, které na tento aspekt nemyslí od začátku mají velké problémy, když se objeví příliš uživatelů, začnou mít mnoho dat a mnoho vzájemně se ovlivňujících se funkcí. Nezvládnou takový tlak a my v těchto aplikacích můžeme i přijít o excelentní nápad, či dobrého pomocníka v každodenním životě. Proto je téma optimalizací důležité a je potřeba se nad ním zamýšlet. Začínají dobrým nápadem a rozvinou se do fáze, kdy přes dnešní výkon počítačů, přestává stačit mít aplikaci napsanou „aby to fungovalo“. V této chvíli se vývojáři teprve uchylují k lazení výkonu aplikace, což zpomalý jejich vývoj a může i dokonce stát službu její život, jelikož se přestává vyvíjet a nebo částečně i fungovat, jelikož jsou nutné větší zásahy do jádra aplikace. I u aplikací, které toto ustojí, je tato fáze velmi obtížná a stojí mnoho zdrojů. Proto je velmi důležité, aby vývojáři měli k dispozici nástroje, které je na případné problémy upozorní dříve než se do této fáze dostanou, případně jim pomohou tuto fázi co nejrychleji překlenout. Tento problém, se snaží částečně řešit tato bakalářská práce. Nyní pouze pro Ruby on Rails framework, později i další Ruby frameworky. 1

Úvod

Motivace Ruby on Rails je velmi silný framework, který dovoluje začátečníkům velmi rychle proniknout do tvorby webu. Zejména díky principům samotného jazyka, jako jednoduchost a čitelnost, které framework dále rozšiřuje. Toto má však za následek, že se pomalu množí začínající vývojáři, kteří si na Rails osvojují webové technologie. Ač framework velmi přispívá k elegantnosti kódu, vždy je tu člověk. A ten má samozřejmě často tendence nalézat složitá řešení tam kde existují jednoduchá a tím se potenciál frameworku pro aplikaci vytrácí. Téma jsem si vybral, protože mne optimalizace velmi zajímá a mám rád algoritmy a nacházení jiných, elegantních cest ke stejnému řešení. Zároveň jsem zaměstnán ve firmě, která vyvíjí RoR aplikaci a je přesně ve fázi, kdy řeší výkonostní problémy, jelikož od začátku nebyl kladen důraz na eleganci kódu.

Cíl práce Cílem bakalářské práce je navrhnout otevřený modulární analyzační nástroj, který by pomohl vývojářům webových aplikací postavených na frameworku Ruby on Rails s kontrolou a analýzou výkonu jejich aplikací. A to jak při vývoji tak i u ostrých aplikací.

2

Kapitola

Současný stav 1.1

Problémy

S roustoucím hladem po webových aplikacích a zjednodušováním návrhu aplikací, které dnešní webové frameworky nabízí, se stále více střetáváme s nezodpovědnými vývojáři, kteří mají nápad a realizují jej nejjednodušší cestou. Tato cesta většinou však nebere ohledy na správnost a efektivitu kódu. Toto vede vývojáře a firmy k doměnkám, že jejich aplikace je velmi náročná a proto si pronajímají výkonnější a výkonnější hardware. Opomínaje alternativu zefektivnění kódu. Toto je velký problém zejména pro rozpočty vývojářských firem. Ačkoli výrobci hardwaru by se mnou možná nesouhlasili. Velké množství začínajících vývojářů začíná programovat webové aplikace bez předešlé zkušenosti, či vzdělání v oboru. Proto je pro ně velmi těžké už jen to, aby aplikace dělala co má a na efektivitu nemají myšlenky.

1.2

Výkon aplikace

V této části bych rád shrnul měřítka výkonu aplikace a typické problémy, které v RoR aplikacích mají negativní dopad na rychlost.

1.2.1

Čas zpracování

Základním měřítkem výkonu aplikace je čas zpracování requestu aplikace. Za jak dlouho, od chvíle kdy webový server zadal aplikaci dotaz, aplikace odpoví. Toto měřítko je to, které nás na straně aplikačního serveru zajímá nejvíce. Nese však jen velmi malou informační hodnotu. V podstatě pouze pomalé/rychlé.

1.2.2

Počet dotazů na databázi

Základem drtivé většiny webových aplikací je databáze. Databáze je však uložena na disku a tudíž při čtení z databáze probíhá čekání na disk. Disk je však velmi pomalý 3

1

1. Současný stav a tím se i databáze stává relativně pomalou. Což v důsledku znamená, že chceme data, potřebná pro daný dotaz načíst v co nejméně dotazech na databázi. U dotazů na databázi měřím čas a počet. Oba údaje by měl mít vývojář stále na očích, jelikož zde zde je možné jednoduše nalézt největší problémy aplikace. Vývojář tuší, co se na dané stránce vykonává a je schopen odhadnout počet potřebných dotazů. Proto je i schopen použít k číslo k nalezení zřejmých chyb.

1.2.3

Rychlost SQL dotazů

U složitějších aplikací se již aplikace nevyhne složitějším dotazům na databázi, zejména pokud vykonává složitější operace s velkým množstvím dat. Proto je velmi zajímavé vidět, jak dlouho trvají jednotlivé dotazy, abychom mohli nalézt případné dotazy, které by bylo dobré podrobit bližšímu zkoumání. S rychlostí dotazů velmi úzce souvisí indexy nad tabulkami databáze.

1.2.4

Načítání dat

1.2.4.1

N+1 query

Problémy s načítáním dat jsou v ActiveRecord řešené pomocí takzvaných preload dotazů. Toto zjednodušuje řešení N+1 query, kdy ve většině případů stačí přidat preload na potřebné místo. Vývojáři však často zapomínají, či přidaná funkcionalita začne používat data, která dříve použita nebyla. Díky lehce čitelnému rails kódu, lze snadno zapomenout, že za ním často stojí dotaz do databáze. Proto je tento problém detekován. 1.2.4.2

Načítání více dat, než je nutno

Další problém s N+1 query je, že je řešen tam, kde by nenastal a jsou načtena data, která nejsou použita. Tento problém je taky detekován. 1.2.4.3

Counter Cache

Jedná se o problém s dotazem na počet subentit. Pokud potřebujeme zobrazit pouze jejich počet, provádíme jeden dotaz na databázi pro každý počet. Tento problém se dá řešit jednoduchým přidáním počtu buď do dotazu načítajícího rodičovskou entitu, nebo do tabulky rodičovské entity přidat sloupec s počtem subentit. Toto rozhodnutí je již na vývojáři a oba přístupy jsou v rails velmi snadné. Úkolem analyzeru je tedy problém nalézt a upozornit na něj.

1.3 1.3.1

Existující řešení New relic

New relic je velmi silný analytický a monitoringový nástroj, který nabízí velmi mnoho funkcionalit, na které se chci zaměřit ve své bakalářské práci. Z tohoto dů4

1.3. Existující řešení vodu byl i hlavní inspirací při implementaci. Tento nástroj nenabízí žádné specifické analyzační funkce specifické pro framework Ruby on Rails. Avšak jeho nevětší nevýhodou je cena, v neplacené variantě nenabízí příliš mnoho funkcionality a pro menší aplikaci je $200 / server / měsíc velmi vysoká cena. Lze monitorovat více aplikací, avšak každá je zpoplatněna zvlášť. Nástroj nabízí nepřeberné množství informací a grafů. Jsou velmi zajímavé, avšak zabere dost času se zorientovat ve významu jednotlivých měřítek. A většina je i pro většinu aplikací ne příliš zajímavá. Na první pohled je rozhraní velmi zmatečné. NewRelic se tedy hodí k monitorování opravdu velkých aplikací, které běží na jednom serveru a podrobný monitoring. Zároveň nejspíše potřebuje minimálně jednoho školeného odborníka na orientaci, aby byla schopna z dostupných dat vytěžit co nejvíce informací.

1.3.2

Miniprofiler

Miniprofiler nabízí asi nejvíce funkcionalit, které jsem u dostupných řešení hledal. Je to velmi známé řešení, které bylo původně napsáno pro .NET, ale nyní existuje jeho varianta pro mnoho webových frameworků. Jedním z nich je Ruby on Rails. Avšak chybí mu těžba dat, z minulosti lze dostat velmi omezené informace. Tím se stává nástrojem pouze pro vývoj. Tomuto nástroji však zejména chybí větší informativní schopnost. Nabízí spíše hlubší pohled na chování aplikace v reálném čase, což může pomoci až když se přímo soustředíme na jednotlivé části aplikace.

1.3.3

Bullet

Dalším nástrojem který stojí za povšimnutí je Bullet. Což je velmi užitečná knihovna. Zaměruje se však pouze na SQL dotazy v Rails aplikaci a základní tři problémy v nich: • N+1 query • Nadbytečné načítání dat • Counter cache Jedná se tedy o velmi úzce specializovaný nástroj, bez samostatného grafického výstupu. Podporuje však mnoho cest jak problémy reportovat do externích monitorovacích aplikací.

1.3.4

Peek

Peek je nástroj soustředící se na lehký vhled do aplikace. Nástroj je líbivý a pěkně napsaný. Nepřináší však příliš mnoho informací. Dodává informace spíše systémové. Zhruba načrtává v jakém se aplikace nachází stavu. Je zejména vhodný pro monitorování ostré či režijní aplikace bez nutnosti vzdáleného připojení. 5

1. Současný stav

Obrázek 1.1: Peek bar Na obrázku 1.1 je vidět, že Peek nabízí monitoring relativně mnoha součástí Rails aplikace. Bohužel však o všech podává jen málo informací. Nenabízí také žádný monitoring.

1.3.5

Rack insight

Rack inside je velmi zajímavý nástroj s dlouhou historií. Nástroj se však snaží podat vývojáři jakýsi přehled a umí nabídnou relativně dost informací. Jeho vývoj byl několikrát přerušen a převzat jiným vývojářem. Bohužel však i podle toho vypadá samotný nástroj. Kód není konzistentní, není příliš intuitivní na instalaci a jeho jednotlivé komponenty občas nefungují jak mají.

Obrázek 1.2: Peek bar

Obrázek 1.3: Peek bar

1.3.6

Sentry

Sentry je aplikace pro monitorování a oznamování chyb. Snaží se zajistit, aby provozovatel aplikace věděl o chybovosti jeho aplikace. Jak s tímto vědomím naloží již aplikace neřeší, jak by také mohla.

1.4

Srovnání Tabulka 1.1: Srovnání řešení

Řešení New relic Miniprofiler Bullet Peek Rack insight

6

Monitoring ++ externě ?

Přehlednost ++ + + -

Informativnost + + -

Cena $200 / server zdarma zdarma zdarma zdarma

Kapitola

Požadavky Poskytnout vývojáři nástroj, který by byl použitelný bez složitého nastavování, či změn ve aplikaci samotné. Tento nástroj by měl vývojáři poskytnout dostatek informací, aby byl při vývoji schopen odhalit potenciální výkonostní problémy a rizika. Neměl by obtěžovat vývojáře, čili vizuální rozhraní nesmí být příliš !extensivní!, neměl by příliš zpomalit fungování aplikace, protože rychlost fungování aplikace je důležitá i při vývoji, jelikož vývojáři jsou často netrpělivější, než jejich uživatelé. Navíc čas vývojáře je drahý. Musí vývojáři dodat informace přehledně a bez námahy, protože vývojáři jsou velmi líní lidé. Zároveň by měl poskytnout nějaký souhrný ukazatel, jak si jeho aplikace vede v čase. A to i na ostré aplikaci. Kde zpomalení aplikace o více než pár procent není únosné a je tedy základním cílem. Cílové řešení by mělo být komunitní a otevřené. Samozřejmě je zde možnost hostování řešení a podpora. Avšak základní použití by mělo být jednoduché, zdarma a pokud je potřeba, upravitelné na míru.

7

2

Kapitola

Realizace 3.1

Použité technologie

Jako cílové aplikace byly vybrány aplikace postavené na RoR. Jelikož je nutné analýzu provádět přímo v aplikaci, použité technologie nebylo příliš těžké vybrat. Ruby on Rails nabízí takzvané enginy, což jsou pluginy do aplikace, které jsou sami o sobě malými RoR aplikacemi. Ty budou základem mého řešení.

3.1.1

Ruby

Ruby je moderní dynamický, objektově orientovaný jazyk se zaměřením na jednoduchost a produktivitu. Nabízí elegantní syntaxi, která je přirozená pro psaní a snadno čitelná [1]. Jeho tvůrce Yukihiro Matsumoto se rozhodl vytvořit Ruby, když po mnoha pokusech zjistil, že nenašel jazyk, který by mu vyhovoval a který by splňoval jeho představy silného avšak jednoduše čitelného jazyka. “I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python [2].”

3.1.2

Ruby gem

Jako každý jazyk, i Ruby má knihovny, které pomáhají programátorům sdílet kód. V Ruby však systém knihoven byl posunut na ještě vyšší úroveň. Pomocí RubyGems se sdílení kódu a používání knihoven stává naprosto triviální záležitostí. RubyGems pro programátora uživatele zvládá instalaci gemu i se všemi závislostmi. Pro programátora gemů je připraveno intuitivní rozhraní pro definování závislostí, předpřipravené souborové struktury, jednoduché vytvoření a publikování balíčku ( gemu ) z kódu. Zároveň poskytuje velmi intuitivní správu verzí. Z výše popsaných důvodů je jen logické, že naprostá většina knihoven pro Ruby je publikována a používána skrze gemy. 9

3

3. Realizace

3.1.3

Rack

Rack je webserver interface pro Ruby. Nabízí minimalistické rozhraní mezi webovým serverem a Ruby aplikacemi [3]. V průběhu posledních let, se rack stal vpodstatě standardem při vývoji Ruby webové aplikace. Takto vypadá aplikace, která na jakýkoli požadavek odpoví „Hello world.“ s HTTP status kódem 200(OK) a v hlavičce nastavený typ odpovědi na HTML. app = Proc.new do |env| [ ’200’, {’Content-Type’ => ’text/html’}, ["Hello world."] ] end Applikace může být naprosto jakýkoli objekt, pokud odpovídá na metodu call s jedním parametrem, kterým je promněné prostředí. Návratovou hodnotou této metody musí být trojice status, hlavičky, obsah( ten musí implementovat metodu each, kterou Rack používá pro „vykreslení“ odpovědi ).

3.1.4

Rack middleware

Rack je však více, než pouhým rozhraním. Používá se zároveň k seskupování a řazení modulů zodpovědných za výslednou odpověď aplikačního serveru. Tato technika je známá jako rack middleware, a spočívá v postupném probublávání requestu mezi jednotlivými moduly, který každý přidá svou trošku do výledné odpovědi. Aplikace je poté výsledkem všech middlewarů a kořenové aplikace. Middleware musí implementovat mimo rackové metody call také konstruktor, který přijímá jako parametr aplikaci, která následuje v řetězu po něm. Tato aplikace může být jak Rack aplikace tak další Rack middleware. V metodě call potom volá následující aplikaci. Middleware samozřejmě může řetěz přerušit a vytvořit svojí vlastní odpověď. Toto se ve vyjímečných případech hodí. Toto provádí například Rails Exception handler v případě vyjímky. Avšak pokud bychom v Middlewaru přerušovali řetězení častěji, začíná Middleware ztrácet smysl, jelikož se z něj stává Rack aplikace.

3.1.5

Ruby on Rails

Ruby on Rails je framework napsaný v jazyce Ruby a je hlavním důvodem rozmachu tohoto jazyka i do anglicky mluvících zemí. RoR je vystavěn na architektuře Model2, která je odvozena z architektury MVC, kterou Model2 upravuje pro použití ve webovém prostředí, kde vizuální komponenty nemohou být přímo řízeny a svázány s modely, neboť jsou to webové stránky a jako takové jsou řízeny více html jazykem samotným. 10

3.2. Navržené řešení Ruby on Rails je publikováno pomocí gemu, a proto je i velmi jednoduché vyvíjet na jednom systému pro více verzí frameworku, bez nutnosti přímého publikování kódů frameworku zároveň s kódy aplikace.

3.1.6

Rails engine

Engine může být považován za miniaturní aplikaci, která poskytuje funkcionalitu svojí hostující aplikaci. Rails aplikace je vlastně „superset“ enginu, s její hlavní třídou Rails :: Application dědící mnoho funkcionality od třídy Rails :: Engine, která je základem enginu [4].

3.2

Navržené řešení

Mnou navržené řešení je zaměřeno přímo na framework Ruby on Rails, avšak je snadno rozšiřitelné i na další Ruby frameworky. Mnou navržené řešení se skládá z dvou hlavních částí a jedné sdílené knihovny. První část je Rails engine, který zajišťuje samotné měření aplikace a ve vývojovém prostředí přidává !!toolbar. Druhá část je Rails engine, který zajišťuje vizualizaci a ukládání výsledků za delší časový úsek. Tento engine je možné použít jak přímo v aplikaci samotné, nebo odděleně, v jiné aplikaci pro sbírání statistik z více serverů. Toto řešení je vhodné jak pro malé aplikaci, které jsou v aktivním vývoji, ty většinou použijí ukládání přímo v aplikaci, ale také pro velké robustní aplikace, které využijí ukládání na do oddělené aplikace. Poslední částí je knihovna, sdílená oběmi hlavními částmi a tou je knihovna takzvaných adaptérů, které slouží pro ukládání výsledků na různá úložiště. Volba úložiť je velmi široká. Výsledky lze ukládat do paměti, což je vhodné zejména pokud se ukládají pouze dočasně pro zobrazení v ladícím panelu. Dále lze ukládat výsledky do paměťových !!persistent úložišť jako Redis, či Memchached. Tato volba je vhodná zejména pro větší aplikace již v produkčním prostředí, jelikož je nejrychlejší metodou, která výsledky zároveň ukládá při restartu aplikace.

3.2.1

Spojení dostupných řešení

Protože mé řešení má být otevřené a komunitní, není problém v něm využít již existující technologie. Rozhodl jsem se tedy využít již dříve zmíněné nástroje Bullet a rack-mini-profiler

3.2.2

Adapter

Adapter slouží k výběru úložiště pro naměřené hodnoty. Prozatím jsou dostupné tyto adaptéry: 11

3. Realizace • Memory Základní adaptér, který výsledky uchovává pouze po dobu běhu aplikace a je užitečný zejména pro nulovou konfikuraci a postačí pro zobrazení aktuálních informací. Neumožňuje však dlouhodobý monitoring aplikace • Redis Umožňuje uložit výsledky do memory based storage. Jednoduchá konfigurace, omezený objem dat. • Memcached Další memory based storage, umožňuje monitorování více aplikací najednou, pravděpodobně nejlepší volba v ostré aplikaci. • InfluxDB Ukládá výsledky do databáze specializované na ukládání časových posloupností. Tuto možnost budou chtít využít zejména lidé, kteří se rozhodnou využít jiné zobrazování, než nabízenou komponentu. Zejména pro nástroj Grafana. • Server Výsledky jsou posílány na vzdálený server pomocí http. 3.2.2.1

Grafana

Grafana je velmi intuitivní a silný nástroj pro zobrazování časových grafů z nejrůznějších zdrojů, jedním z nich je také InfluxDB. Je tedy jednou z možností jak sledovat výkon aplikace v průběhu času, při použití InfluxDB databáze. V přílohách je k dispozici příklad nástěnky pro grafanu. Stačí nahrát a nastavit svůj zdroj data influxDB databáze, do které aplikace posílá svá data.

3.2.3

Analyzer

Analyzer je modulární a jeho hlavní částí jsou takzvané collectory, které sbírají data z různých částí aplikace. Analyzer je navržen jako rack middleware, který při příchozím requestu nastaví proměnné a prostředí pro měření a předá řízení aplikaci. Po dokončení requestu ( aplikace vrátí http response ) Analyzer vyhodnotí výsledky z collectorů a 1. uloží je pomocí vybraného adaptéru, 2. pokud je povolen, vyrenderuje development panel. Panel není generován přímo, ale místo něj je vložen pouze placeholder. Data do panelu jsou poté načtena dalším requestem pomocí AJAX, aby nezpomalovala request samotný.

3.2.4

Vizualizer

Vizualizer je hlavním viditelným výstupem zejména užitečným v produkčním režimu na ostré aplikaci, kde se nehodí zobrazovat toolbar ( i když i to je možné ). Umožňuje přehled za delší časové období ( chybovost, průměrná rychlost jednoho requestu ). Období lze nastavit. Vizualizer zároveň přidává možnost ukládat výsledky do databáze. Do budoucna je potřeba zpracovat zobrazování dat i z jiných úložišť, aby nebylo nutné výsledky 12

3.2. Navržené řešení posílat přímo aplikaci, která se stará o zobrazování ( jelikož se nejedná o nejrychlejší metodu, pokud aplikace nejsou ve stejné síti). Pro vizualizer jsou nyní adaptery pouze pro ukládání dat zároveň do více úložišť, pokud bychom chtěli využít i jejich možností. Vizualizer může monitorovat více aplikací, avšak pokud výsledky posíláme z jiné aplikace musíme ji nejdříve zaregistrovat. Ověření aplikace probíhá přes vygenerovaný api klíč, který zkopírujeme do konfiguračního souboru monitorované aplikace

13

Kapitola

Použití OBR - communication diagram

4.1

Konfigurace

Aplikace dodržuje návrhový vzor „Convencion over configuration“ a ve vývojovém prostředí není třeba nic nastavovat. Je přednastaveno ukládání do paměti, cesty Enginu využité při načítání dat toolbaru se automaticky namapují. Ve vývojovém prostředí se zobrazí toolbar. Po přidání Vizualizeru přímo do aplikace se adaptér automaticky nastaví na databázi. Vizualizer ve vývojovém prostředí tedy také funguje bez nutnosti konfigurace. V produkčním prostředí již je nutná alespoň minimální konfigurace, jelikož nám již nestačí ukládat výsledky do paměti. Nechceme také nejspíše ukládat výsledky ve stejné aplikaci, ale chceme Vizualizer přidat do aplikace, se kterou budeme komunikovat přes HTTP protokol. Konfigurace gemu je možná přes konfiguraci aplikace, v podsekci speedup. Do souboru config/environments/production.rb bychom tedy přidali například: config.speedup.adapter = :server, { url: ’http://localhost:8080’, api_key: ENV[’SPEEDUP_API_KEY’] }

4.1.1

Adaptér

U většiny adaptérů je možné, většinou nutné další nastavení. Většinou umístění a přístupové údaje k úložišti. Další dostupná nastavení: • show_bar boolean - zobrazit toolbar, či nikoliv 15

4

4. Použití • automount boolean - automaticky připojit cesty do cest aplikace. • collectors array - pole použitých Collectorů.

4.1.2

UI

Rozhraní pro Analyzer je velmi jednoduché a je inspirováno designem Tracy panelu z Nette - českého php frameworku.

Obrázek 4.1: Toolbar Na obrázku 4.1 je vidět základní panel Analyzeru. Po najetí na některé části se otevře okno s detaily ( queries, problems, partials ).

16

Závěr

17

Literatura [1] community, R.: Ruby. 2010, [Online; accessed 24-04-2015]. Dostupné z: https: //www.ruby-lang.org/en/ [2] Stewart, B.: An interview with the Creator of Ruby. 2001, [Online; accessed 20-04-2015]. Dostupné z: http://www.linuxdevcenter.com/pub/ a/linux/2001/11/29/ruby.html [3] Rack: Rack documentation. Dostupné z: http://rack.github.io/ [4] Ruby on Rails: Rails Guides [online]. [cit. 2015-04-10]. Dostupné z: http:// guides.rubyonrails.org/engines.html

19

Příloha

Seznam použitých zkratek RoR Ruby on Rails UI User interface GUI Graphical user interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol SQL Structured Query Language AJAX Asynchronous JavaScript and XML

21

A

Příloha

Obsah přiloženého CD

readme.txt....................................stručný popis obsahu CD exe...........................adresář se spustitelnou formou implementace src impl......................................zdrojové kódy implementace thesis..........................zdrojová forma práce ve formátu LATEX text..........................................................text práce thesis.pdf................................text práce ve formátu PDF thesis.ps...................................text práce ve formátu PS 23

B