Hlavní navigace

Cocoon v příkladech: Výkonnost a nasazení v jiných servletových kontejnerech

Pavel Sýkora

V pátém dílu tohoto seriálu jsem uvedl výsledky testování rychlosti a výkonnosti aplikace v Cocoonu na svém domácím počítači. Dnes se lehce podíváme na docela zajímavé výsledky výkonnostního testování na "opravdovém" serveru. Pak si řekneme, jak nasazovat cocoonovské aplikace v jiných servletových kontejnerech (např. Tomcat).

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:

  1. Zkopírujeme soubor build.properties do souboru local.build.pro­perties.
  2. Zkopírujeme soubor blocks.properties do souboru local.blocks.pro­perties.
  3. Vyloučíme z kompilace všechny nepotřebné části odkomentováním nastavení exclude.* v souboru local.build.pro­perties. Rozhodně nebudeme potřebovat žádnou dokumentaci k Cocoonu, Javadoc ani příklady. Vhodné je také volbu compiler.debug nastavit na hodnotu off, a pokud jsme vyloučili veškerou dokumentaci, musíme zakomentovat volbu  exclude.validate.xdocs= true.
  4. Vyloučíme z kompilace všechny nepotřebné bloky odkomentováním nastavení exclude.* v souboru local.blocks.pro­perties. 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/we­bapp 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.

Našli jste v článku chybu?
28. 4. 2004 20:29
Jerry III (neregistrovaný)

Jenze load test nema simulovat bezneho uzivatele, to bys pak mel opravdu tisice konexi generujicich par hitu za nekolik minut. Ucelem load testu je videt co je dana aplikace schopna zvladnout, jak se bude chovat pod zatizenim, ne behem bezneho provozu ve tri rano.

28. 4. 2004 15:41
Pavel Sýkora (neregistrovaný)

Predem musim varovat, ze Struts znam jen povrchne. Ale rekneme, ze budu chtit vytvorit nejaky portal. Pokud vim, tak Struts zadnou primou podporu portalu neobsahuje (existuje vsak nekolik portalovych enginu zalozenych na Struts - viz napr. http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view - asi bych se na ne take kouknul). Samozrejme mi nic nebrani tomu, abych pomoci Struts nebo jen JSP, servletu nebo treba Perlu, PHP, C (nebo VisualBasicu :-)nenaimplementoval fun…