Názory k článku Cocoon v příkladech: Výkonnost a nasazení v jiných servletových kontejnerech
-
Článek je starý, nové názory již nelze přidávat.
-
Jerry III (neregistrovaný)
Tomu rikate test vykonu? 40 uzivatelu tahajicich necelych 100 KB/sec? To zvladne i personal web server ve Win98... To nas obstarozni IIS 5 na dual P3 Xeonech na 850Mhz s 1 GB pameti zvladal vytlacit skoro 6 MB/sec pri 200 uzivatelich vyzadujicich Asp.Net stranky (a ne zadny staticky data, minimum byly dva dotazy do databaze a zobrazeni vysledku), a vys to neslo protoze klienti byli pripojeny jen 10Mbitovou siti :( Nemluve o tom ze nestihali generovat log, meli sme jen 4 masiny a byly vytizeny na 80+%. Leda ze by ten test byl opravdu maximem co je Cocoon na tak nadupany masine zvladnout a pak je to dobry leda tak na ty samy dve veci na ktery sou dobry vsechny Java based frameworky.
-
Pavel Sýkora (neregistrovaný)
No, jsem trochu v rozpacich. Mas pravdu, ze pokud bych mel delat projekt, kde prioritou bude maximalni vykon na co nejslabsim zeleze, tak si Cocoon nevyberu ani ja (prestoze se mi jeho architektura a moznosti jinak docela libi).
Na druhe strane mi prijde u tvych cisel divne, ze 200 uzivatelu udela traffic 6 MB/s. To znamená 30 KB/s na uživatele. Moc si neumim predstavit, co prumerny uzivatel s takovymi informacemi dela (pokud se ten vysledek databazoveho dotazu nerenderuje napr. jako nekomprimovane BMP :-). Ja, kdyz si otevru stranku, ktera ma 30 KB, tak ji ctu urcite nejmene minutu (casto asi i vice). Z tohoto hlediska mi prave 40 uzivatelu tahajicich 100 KB/s (tj. 2.5 KB/s = 150 KB/min na uživatele) prijde spise jako abnormalne velky provoz (tedy na 40 uživatelu). Ale jiste se mohou najit webove aplikace, které beznemu modelu neodpovidaji. -
Jerry III (neregistrovaný)
V jednom prispevku? To teda nevim... Jsou to frameworky, kazdej je trochu jinej, existuje spousta dalsich, zadnej z nich neni nejlepsi na vsechno, jako vubec vsechny veci. Neco se hodi na jeden problem, neco jinyho na jiny. Vyber si nejakej kterymu rozumis, ve kterym se ti dobre dela a kterej zvladne to co po nem chces (v tomhle poradi). Rozhodne nepouzivej neco jen proto ze si cetl clanek kterej tvrdil ze je to nejlepsi.
-
Pavel Sýkora (neregistrovaný)
Já osobně bych konkrétně na portál spíše volil Cocoon Obsahuje na to speciální frameworky a jeho architektura je na to též docela vhodná. Ovšem je nutné se smířit s dosti strmou učební křivkou a pokud se nejedná o týmovou projekt, tak je třeba počítat s tím, že jeden člověk musí toho zvládnout opravdu hodně. Ale opravdu záleží nejvíce na tom, jake jsou výchozí podmínky a požadavky daného projektu.
-
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 funkcionalitu portalu. Ale to uz je v Cocoonu (presneji v Cocoon Portal Frameworku) (skoro) hotove a rekl bych, ze je v tom opravdu hodne prace, kterou bych jinak musel udelat sam. Pak bude nejspise potreba nejak sjednotit datove zdroje (nemluvim ted o jejich prezentaci), ktere budu prezentovat na portalu. Zde mi nahrava architektura a hotove komponenty Cocoonu, ktere by 40-80 % me potreby mohly pokryt (v zavislosti na tom, jak exoticke datove zdroje budu chtit prezentovat). Ale par jich budu asi taky muset vytvorit. Pak musim udelat navrh a implemetaci logiky a grafiky jak portalu samotneho, tak jednotlivych portletu. V Cocoonu to bude znamenat napsani nekolika XSL a CSS stylesheetu, nejake fragmenty XHTML a vytvoreni konfiguracniho souboru. Nejvice mi praci bude komplikovat fakt, ze k tomu Cocoon portal frameworku (ani k jednomu z tech dvou) neni moc dokumentace, takze se budu muset obcas podivat do kodu komponent. Nicmene, pokud si to nekdo u mne objedna, tak mu prototyp (bez hezke grafiky a osetreni chyb) dodam, rekneme, do tydne a ve dvou, trech lidech by to mohlo byt hotovo a odladeno do mesice az sesti tydnu. Cocoon mi zajisti, ze portal bude opravdu flexibilni a udrzovatelny, takze pokud bude zakaznick chtit nejakou rozumnou zmenu (rekneme pridat portlet s podobnym datovym zdrojem), bude mi to trvat maximalne par hodin.
Rozhodnu-li se pro hole Struts, zacnu tim, ze se to poradne naucim (no, dobre, rekneme, ze to je muj problem :-), pak zacnu hledat, jake standardy jsou pro portaly a zacnu to programovat. No, rekl bych, ze tak za dva mesice budu moci rict zajemci, ze sice zatim nic nemuze videt, ale ze uz mam skoro odladene API, knihovny tagu a podobne veci, ktere budu pro ten portal nutne potrebovat. Ale je mozne (ci snad dokonce pravdepodobne), ze to cele nakonec bude mit o neco lepsi (o 10-20 % ?) vykonnost nez reseni zalozene na Cocoonu.
Nerad bych poslednim odstavcem podnitil nejaky flame. Struts neznam do detailu, takze je mozne, ze moje predstava je prilis pesimisticka (nebo taky optimisticka). Konec koncu Struts a Cocoon nemusi byt jen konkurenty, podivejte se treba sem: http://struts.sourceforge.net/struts-cocoon/ .
ČLÁNKY DO MAILU