Dva pozadavky za sekundu - tomu rikate testovani vykonu? Osobne mi je putna jak rychla je aplikace kdyz ji nikdo nepouziva. Co takhle to poradne zatizit? Osobne svoje aplikace testuju tak ze posilam requesty jak rychle to jde z nekolika desitek "klientu" a koukam kolik jich dana aplikace dokaze vyridit (a za jak dlouho). To ze mi aplikace naserviruje stranku za ctvrt sekundy kdyz ji nikdo nepouziva je opravdu irelevantni, me by zajimalo nakolik ten cas naroste az tam bude 100 soucasnych pozadavku. Co takhle udelat poradnej test?
Jo a rikat - pokud mate vic jak dve transformace tak predelejte aplikaci - to nemyslite vazne ne? Pokud se Cocoon na neco nehodi (jako treba aplikace slozitejsi nez foto album) tak reseni neni prizpusobit aplikaci Cocoonu ale pouzit framework co se hodi (Struts?).
Namet byl opravdu spise o "rychlosti" roury v danych podminkach nez o vykonu aplikace. Na svem domacim pocitaci s necelymi 400 MB RAM, kde bezeli klienti se serverem najednou, bych si patrne ani nemohl dovolit dat 100 soucasnych dotazu. Server i klienti by zacali swapovat a ta cisla by asi nebyla k nicemu. Ale dik za namet, pokud se dostanu k nejakemu prostredi, kde si to budu moci dovolit, tak to zkusim.
Jinak jsem nemyslel dve transformace jako takove, ale dve a vice XSLT transformaci. Pokud mame tu volnost definovat i strukturu pocatecniho XML, tak je to obvykle mozne vzit v uvahu uz ve fazi designu.
Struts je rozhodne renomovany framework a ackoliv jej prilis neznam, tak se mi zda, ze je hodne o programovani v Jave. Cocoon je, podle meho nazoru nekde jinde. Neni tak orientovan na programovani (psani vlastnich komponent a bloku v Jave je v Cocoonu uz hodne "advanced"), ale spis uz toho obsahuje mnoho hotoveho, co staci jen poskladat do roury. Je vsak mozne, ze pokud si date za cil co nejvetsi vykon na co nejslabsim hardware, Struts muze byt lepsi volbou.
Uznavam ze 400MB pameti neda moc kvalitni vysledek, ale to jak rychle to prozene jeden pozadavek je fakt relativne nezajimavy cislo... V zavislosti na tom jak je framework napsanej muze bejt bleskovej s jednim requestem ale totalne se polozit pod zatezi anebo muze vypadat jako relativne pomalej ale drzet i kdyz zpracovava hodne pozadavku :) Rozhodne by to bylo zajimavy videt jak se zachova s nekolika desitkama klientu...
Co se tyce struts tak je to urcite neco jineho nez Cocoon, Cocoon je zamerenej na zobrazeni dat, ne jejich zpracovani. Struts je implementace MVC, oddeluje zpracovani pozadavku (naprogramovany Jave) od zobrazeni dat uzivateli (psany v JSP s JSTL a custom tagama). Takze ano, sou to jabka a hrusky, ale pokud se clovek rozhoduje v cem napsat projekt tak cim vic toho ma na vybrani tim lip, dopadne to lip nez se snazit roubovat veci na ten jeden framework co znam :)
Neni to tak uplne pravda. I kdyz by to nebylo uplne v duchu Cocoonu, tak by se daly napsat v Jave transformatory, ktere by mohly byt hodne podobne soucasnemu reseni. Navic by kdykoliv sla pouzit uz ta spousta hotovych komponent a bloku, nebo v budoucnu lehce prejit na XSLT nebo STX apod.
Jako vice nez zajimavou alternativu bych doporucil FreeMarker - http://www.freemarker.org. Mam s nim ty nejlepsi zkusenosti a v nove verzi umoznuje i alternativni zpusob XML transformace ktera je znacne prijemnejsi nez XSLT nicmene jsem to v praxi jeste nevyzkousel (see http://www.freemarker.org/docs/xgui.html).
Pokud jde o efektivitu XSLT a STX, STX by melo byt rychlejsi, ale zatim bohuzel jen teoreticky. STX je zatim stale ve vyvoji a procesory nejsou dostatecne optimalizovane. Shodou okolnosti pred nekolika dny poslal Eric van der Vlist do STX listu vysledky svych experimentu s Cocoonem a XSLT vs. STX. Zejmena Saxon je zatim nedostizny (ale na Joostu se intenzivne pracuje :)
Pro zajemce: http://archive.gingerall.cz/archives/public/stx2003/msg00471.html