Případová studie

Během testování a profilování jsme nalezli a odstranili slabá místa v aplikaci a pronikavě tak zvýšili její výkon. Díky zátěžovým testům jsme mohli zákazníkovi dodat informace o chování systému při běžném provozu i při zvyšování zátěže. Testy škálovatelnosti pak odhalily problémy na straně databáze a ukázaly, kterým směrem je třeba zaměřit další úsilí při optimalizaci aplikace.

Zákazník: YONC Technologies

Přemýšlejte: než denně ztrácet čas brouzdáním po internetu a hledáním informací, co kdyby se novinky prostě objevily na Vašem desktopu? A to je YONC – Your Own News Collector, služba která shromáždí informace informace relevantní právě pro Vás. Tvůrcem této služby je YONC Technologies, norská softwarová společnost se sídlem ve Stavangeru.

Dodavatel: AspectWorks, s.r.o.

Vývoj softwaru na míru, služby v oblasti procesní analýzy a workflow, outsourcing IT, kontrola kvality, odborná školení – to vše nabízí softwarová společnost AspectWorks. Specializujeme se zejména služby a řešení, vyžadující nadstandardní znalost technologií, vysokou osobní profesionalitu, spolehlivost a orientaci na potřeby uživatele.

Testovaný systém

YONC server je serverové řešení pro pracování dat z RSS kanálů, jejich filtrování a distribuci klientům. Systém zpřístupňuje velkému množství uživatelů z celého světa sadu webových služeb (web services), poskytujících novinové zprávy, filtrované dle individuálních nastavení uživatelů. Umožňuje též přístup vytvářet skupiny zpravodajských kanálů a sdílet tyto skupiny mezi více uživateli.

Vzhledem k tomu, že jde o sadu webových služeb, může data poskytovaná YONC serverem využívat libovolná klientská aplikace, ať už se jedná o web, čtečku RSS feedů* nebo např. widget. Důležitou cílovou platformou je také Lotus Notes.

Nové funkce systému, založené především na sdílení a publikování skupin zpravodajských kanálů definovaných uživateli, vyžadovaly použití flexibilní bezpečnostní architektury. Díky zvolené architektuře Spring Security (Acegi) bylo možné integrovat systém s různými adresářovými službami, jako je např. LDAP nebo Microsoft Active Directory. Architektura samozřejmě podporuje též WS-Security.

Testovací prostředí

Pro testování bylo zapotřebí v krátkém čase vybudovat testovací infrastrukturu podobnou produkčnímu prostředí zákazníka. Pro vlastní běh aplikace jsme použili 4 servery s QUAD procesory, každý s 8 GB paměti. Tyto servery byly zapojeny do clusteru pomocí Apache Load Balanceru. Podle potřeby jednotlivých testů jsme do clusteru zapojovali různý počet serverů.

Pro generování zátěže byl použit nástroje JMeter jakarta.apache.org/jmeter »  v distribuovaném zapojení. Toto zapojení umožňuje efektivně rozložit výkon, takže řídící počítač tohoto clusteru není zatížen a lze použít i pro monitorování.

Výkonnostní testy

Výkon systému závisí na velkém množství parametrů a každý z nich přidává do měření novou dimenzi, násobí počet nutných měření a tím i dobu nutnou k testování. Při testech výkonu je nezbytně nutné vybrat co nejmenší počet parametrů, které by ještě přinesly relevantní výsledky. Řešili jsme tedy otázku, které parametry sledovat, a které jsou z hlediska zákazníka nepodstatné.

Provedené výkonnostní testy skutečně potvrdily nedostatečný výkon aplikace a potvrdily i potřebu výkonové optimalizace.

Optimalizace

Pro ladění výkonu aplikace jsme použili zejména nástroj JProfiler. Ten nám umožnil odhalit slabá místa a zaměřit se na jejich optimalizaci. Teorie říká, že pro odstranění 80% výkonnostních problémů stačí optimalizovat cca 20% aplikace a tento odhad se potvrdil i v našem případě.

Příkladem optimalizace byla například změna způsobu autentizace protokolem LDAP. JProfiler ukázal, že binding* při autentizaci je příliš pomalý a provádí se opakovaně při každém volání služby. Tato činnost spotřebovala cca 25% veškerého času běhu aplikace.

Řešením bylo vytvoření skupiny spojení a jejich opakované využívání, čímž jsme odstranili potřebu neustálého vytváření nových spojení. Změna architektury nám umožnila úplně odstranit pomalý binding a aplikaci značně urychlila.

Podobných výkonnostních optimalizací jsme provedli několik (řádově desítky), čímž se výkon aplikace zvýšil přibližně o 1000%. Po optimalizaci již rychlost aplikace byla dostatečná na to, aby přestala být omezujícím faktorem propustnosti systému, což jasně ukázaly pozdější testy škálovatelnosti. Zátěžové testy prokázaly, že optimalizace byla úspěšná a že systém je připraven na reálný provoz.

Zátěžové testy

Nejdůležitějším úkolem při přípravě zátěžových testů bylo sestavit testované scénáře tak, aby se podobaly reálnému provozu. Vycházeli jsme z případů použití (use cases), nicméně jednotlivé testy bylo třeba spouštět s takovou frekvencí, která odpovídá reálnému použití.

Zákazník navrhl tři varianty testů, zaměřené na vysoký podíl operací zápisu (tedy takových operací, při kterých se zapisují uživatelská nastavení do databáze). Přijal také náš návrh na provedení sady testů s vysokým podílem čtení, neboť dle našich zkušeností uživatelé neprovádějí nastavení svých RSS kanálů příliš často, daleko častěji jen čtou nové zprávy.

Během výkonnostních testů jsme testovali:

• čas odezvy systému v závislosti na počtu uživatelů
• maximální počet uživatelů při kterém ještě systém dosahuje stanoveného času odezvy
• odezvu serveru, poskytujícího RSS feedy, v závislosti na počtu feedů
• vliv počtu uživatelů na čas odezvy pro daný poměr operací čtení / zápis

Jak ukazuje ilustrace, k měření jsme použili 2 servery (Machine 1 a Machine 2) zapojené do clusteru a pracující nad společnou databází. Protože jsme předpokládali, že databáze by mohla mít značný vliv na výkon, použil každý ze serverů vlastní kopii databáze, které synchronizoval replikací.

Zátěžové testy prokázaly, že systém je připraven pro reálné použití. Dle očekávání, výkon systému ve scénáři s vysokým podílem čtení byl výrazně vyšší než ve scénářích s vyšším podílem zápisu.

Testy škálovatelnosti

Test škálovatelnosti měl prokázat zvýšení propustnosti zatíženého systému v případě přidání dalšího stroje do clusteru. V rámci tohoto testu jsme měnili počet serverů zapojených do clusteru od 1 do 4. Předpokládali jsme, že aplikace YONC server bude při malém počtu serverů limitujícím faktorem výkonu, takže přidání dalších serverů se projeví vzrůstem výkonu clusteru.

Oproti předpokladům, výkon clusteru zůstal i po přidání dalších strojů stejný, žádnou závislost na počtu serverů jsme nepozorovali. Další testy prokázaly, že již při provozu na jednom serveru je optimalizovaný YONC server tak výkonný, že nepředstavuje žádné významné omezení propustnosti. Slabým článkem byla ovšem použitá databáze. Vzhledem k tomu, že práce na databázi byla mimo rozsah projektu a zákazník nepožadoval ladění jejího výkonu, ukončili jsme testování podle původního plánu, test prokázal, že řešení nelze škálovat přidáváním dalších serverů. Protože možnost škálování aplikace přidáváním dalších serverů je významným požadavkem, rozhodl se zákazník optimalizaci databáze řešit později formou samostatného projektu.

Závěr

Během celého projektu se nám vyplatila pečlivá příprava. Na základě předchozích zkušeností s podobnými projekty jsme dokázali předem eliminovat většinu faktorů, méně podstatných pro měření, a provádět jen ta měření, u kterých se daly očekávat relevantní výsledky. To nám umožnilo provést testy v relativně krátkém čase několika týdnů.

Díky výsledkům, zpracovávaným již během testů, jsme vždy včas zaznamenali trendy, naznačující nesprávný odhad hodnot před testováním. Průběžné korekce nám v několika případech umožnily testovat jiné rozsahy hodnot, než bylo původně naplánováno, a vyhnout se tak ztrátám času, spojeným s opakovaným měřením. Zvláště v případě scénářů s převahou čtení jsme naměřili řádově vyšší výkon než jsme původně očekávali. To je sice dobrá zpráva pro zákazníka, ale pokud bychom problém včas nezaznamenali, bylo by několikadenní měření prakticky bezcenné.

Jediným testem, který nedopadl podle plánu, zůstal test škálovatelnosti. Nicméně i v tomto případě test vedl k velmi cenným poznatkům, neboť prokázal, že zvolené databázové řešení významně limituje výkon celé soustavy.

Výsledky projektu jasně ukázaly, kde leží výkonové hranice testovaného systému, jaký počet uživatelů může daná hardwarová konfigurace obsloužit a také kterým směrem by se měl ubírat další vývoj, aby zákazník získal dobře škálovatelné řešení.

Hodnocení zákazníka

Hlavním důvodem tohoto projektu z naší strany bylo, že jsme si chtěli být co nejvíce jisti výkonem systému před tím, než ho použijeme v ostrém provozu. S tímto produktem se kromě podnikové sféry totiž zaměřujeme i na běžné uživatele v podobě volně dostupného řešení. A pokud pak zveřejníte na webu nějaký nový produkt, který je přístupný všem, a jehož počet uživatelů se rapidně zvyšuje, tak je pro systém zásadní, aby byl schopný reagovat na všechny požadavky rychle a včas. Pokud tomu tak nebude, tak uživatelé produkt opustí nebo odinstalují a většina z nich už ho nikdy znovu nezkusí, což může mít pro váš business katastrofální důsledky.

Rozhodli jsme se na tomto produktu spolupracovat na tomto projektu s AspectWorks, protože jsme cítili, že disponují nejlepšími znalostmi, zkušenostmi a interními procesy potřebnými ke splnění námi požadovaných úkolů. Kromě toho měli praktickou zkušenost s většinou frameworků, které používáme nebo plánujeme používat.

Brzy bylo zřejmé, že tento projekt se bude muset zabývat komplexním a pokročilým testováním, a že bude nutno učinit mnoho důležitých rozhodnutí. AspectWorks zajistili, že všechny zásadní otázky byly vzneseny a diskutovány místo toho, aby byly hledány nějaké nepřiměřeně krátké cesty k cíli. Tímto nám umožnili získat dobrý přehled o stavu výkonnosti systému a díky tomu jsme byli schopni učinit důležitá rozhodnutí o budoucích úkolech a plánech. Konečný report o zátěžovém testování je pak pak vhodným ujištujícím dokumentem pro naše zákazníky, protože jim ukazuje, že to s výkonností našeho systému myslíme vážně.