Testování výkonnosti
Na wiki.cocoondev.org se před časem objevily výsledky testování výkonnosti cocoonovské aplikace pomocí nástroje siege. Zde je například výsledek pro dvouhodinový běh čtyřiceti současných uživatelů, kteří požadovali deset různých URL (převzato z výše uvedeného zdroje):
Transactions: 2077162 hits Availability: 100.00 % Elapsed time: 7200.46 secs Data transferred: 703126566 bytes Response time: 0.14 secs Transaction rate: 288.48 trans/sec Throughput: 97650.23 bytes/sec Concurrency: 39.93 Successful transactions: 2077162 Failed transactions: 0 2066337 pages delivered in interval 0 - 1 s 4869 pages delivered in interval 1 - 2 s 109 pages delivered in interval 2 - 3 s 34 pages delivered in interval 3 - 4 s 5 pages delivered in interval 5 - 6 s 0 pages delivered in interval 6 - 10 s 0 pages delivered in interval 11 - 20 s 0 pages delivered in interval 21 - 30 s 0 pages delivered in interval 31 - 180 s 0 pages delivered > 181 s 2071354 pages total delivered ~99,76 % < 1 sec.
Více než 99 % stránek bylo dodáno do jedné sekundy, to není, myslím, špatný výsledek. Pravda, je na to potřeba patřičný hardware, vyladění JVM i konfigurace Cocoonu. Na výše uvedeném odkazu najdete i výsledky pro 80 a 160 současných uživatelů. Zvláště ten poslední případ je zajímavý tím, že uvedený hardware už tu zátěž přestával „stíhat“, nicméně všechny HTTP požadavky byly vyřízeny.
Jiné servletové kontejnery
Ačkoliv Cocoon obsahuje vestavěný servletový kontejner Jetty, někdy může být potřeba nasadit cocoonovskou aplikaci v prostředí jiného servletového kontejneru. Důvody mohou být různé (například výkon), nejčastějším důvodem však určitě bude fakt, že nějaký servletový kontejner je již v požadovaném místě nasazení provozován. Podívejme se, jak například nasadit aplikaci v Tomcatu. Upozorňuji, že tento postup je spíše „ad hoc“ než správný či dostatečně sofistikovaný. Je určen hlavně pro ty zájemce, kteří by si chtěli takové nasazení jednoduché aplikace „nezávazně“ vyzkoušet.
Záloha naší aplikace
Naše aplikace, které jsme tvořili v minulých dílech, jsme umisťovali do adresáře build/webapp
, který byl vytvořen po kompilaci Cocoonu v základním adresáři Cocoonu (pro verzi 2.1.4 nejčastěji ~/cocoon-2.1.4
). Protože pro nasazení je potřeba Cocoon rekompilovat, je bezpodmínečně nutné naši aplikaci (například fotoalbum zdruhého dílu seriálu) uložit někam jinam, neboť adresář build
bude smazán včetně podadresářů.
Konfigurace
Protože není reálné nasazovat jednoduchou aplikaci se všemi bloky Cocoonu (soubor war by měl pak velikost okolo 50 MB), je nutno specifikovat, které části Cocoonu se mají použít. K tomu slouží tyto kroky:
- Zkopírujeme soubor
build.properties
do souborulocal.build.properties
. - Zkopírujeme soubor
blocks.properties
do souborulocal.blocks.properties
. - Vyloučíme z kompilace všechny nepotřebné části odkomentováním nastavení
exclude.*
v souborulocal.build.properties
. Rozhodně nebudeme potřebovat žádnou dokumentaci k Cocoonu, Javadoc ani příklady. Vhodné je také volbucompiler.debug
nastavit na hodnotuoff
, a pokud jsme vyloučili veškerou dokumentaci, musíme zakomentovat volbuexclude.validate.xdocs=
true
. - Vyloučíme z kompilace všechny nepotřebné bloky odkomentováním nastavení
exclude.*
v souborulocal.blocks.properties
. Pozor na závislosti (jsou většinou popsány v komentářích), ale obecně se dá říci, že pro jednoduchou aplikaci typu fotoalbum nebudeme potřebovat žádný z uvedených bloků.
Rekompilace Cocoonu
V základním adresáři Cocoonu příkazem
build clean
„vyčistíme“ adresář build
a příkazem
build
rekompilujeme Cocoon podle nastavených properties. Dobrá zpráva je, že za těchto podmínek je kompilace poměrně rychlá. Nyní do adresáře build/webapp
znovu zkopírujeme naši aplikaci nebo aplikace. Vytvoříme webový archiv pomocí příkazu
build war
Výsledný soubor cocoon.war
najdeme v adresáři build/cocoon-2.1.4
. Soubor má asi 12 MB a obsahuje kromě naší aplikace vše, co je potřeba k běhu (tj. Cocoon samotný, konfigurace a závislé knihovny jar).
Nasazení a spuštění
Soubor cocoon.war zkopírujeme do adresáře webapps Tomcatu a spustíme jej (případně restartujeme, u novějších verzí však restart není potřeba). Pokud Tomcat používá standardní nastavení a běží na lokálním počítači, spustíme aplikaci (v tomto případě fotoalbum) zadáním URL v prohlížeči:
http://localhost:8080/cocoon/album/
Všimněte si, že na rozdíl od vestavěného serveru Jetty přibylo v URL pro „cizí“ servletový kontejner „…/cocoon/…“. Je to pochopitelné, neboť se počítá s tím, že v kontejneru běží i jiné aplikace. Nezapomeňte v URL na ukončující lomítko – jde pořád o aplikaci v Cocoonu!
Závěr
Testy potvrzují, že se není potřeba bát nedostatečné výkonnosti řešení založeného na XML a transformacích XSLT (pokud ovšem aplikace běží na dostatečně dimenzovaném hardware, což se týká zvláště dostatku operační paměti). Snad to také přispěje ke zbourání mýtu, že co je založeno na XML a ještě k tomu v Javě, musí být zákonitě pomalé.
Bezproblémové nasazování cocoonovských aplikací v servletových kontejnerech zase staví Cocoon do pozice seriózního frameworku pro webové aplikace (což možná nebylo úplně zřetelné z minulých dílů seriálu). Zajímavá diskuse k článku Cocoon as a Web Framework o praktických zkušenostech s Cocoonem se rozvinula na TheServerSide.com. Zaujalo mne tam srovnání Struts a Cocoonu: Struts is the McDonald's while Cocoon is like your Mom's home cooking.
Příště se podíváme na open-source i komerční produkty založené na Cocoonu, a zbude-li trochu místa, tak i na konkurenční frameworky založené na stejném principu jako Cocoon.