Tamás

Dühöngő

©   Tamás   |   hwsw
20

Hogy a jó életbe' tarthat egy egyszerű J2EE+JSP alkalmazás fordítása 2 perc 14 másodpercig??? Valami Java szakértő felvilágosíthatna, hogy ez miért olyan fasza, mint amilyennek kikiáltják.

Update: csak a teljesség kedvéért, mielőtt valaki azzal kezdené, hogy szar a gépem, igen, tényleg szar. 1.4 GHz Centrino, 512 MB RAM. Na de könyörgöm, ez majdnemhogy egy Hello World! szintű program mindössze... Akkor számoljunk egy picit utána. Szokásos edit-compile-test fejlesztési módszert feltételezve ez azt jelenti, hogy ha extrém gyorsan editálok, akkor is két és fél perc, amíg lefordul a program, utána még másfél perc, amíg a tesztelésnél az alkalmazásszerver lefordítja a JSP oldalt (mert azt a deploy során nem teszi meg), és így kb négypercenként jutok el oda, hogy újból szerkeszthessem a programot. nem számolva a swappeléssel járó időkiesést, ami minimum további fél perc, ugyanis a fordítás és a deploy kitol gyakorlatilag mindent a memóriából a swapre, beleértve a Firefoxot is, amiben tesztelek. Azt hiszem, nem ezt hívják rapid application development-nek.

20 hozzászólás

RSS: hozzászólások ehhez a bejegyzéshez 20 hozzászólás

Szólj hozzá Te is!


2) palacsint
Akkor lehet, hogy pont a swapelés miatt tart addig
válasz

3) Haszprus
na milyen jó ez a java, megtanít elsőre jól megírni a hello worldöt, hogy a komolyabb alkalmazásokról már ne is beszéljünk
válasz

4) XYBeR
vegyél még legalább fél giga memóriát, és minden problémád megoldódik. nem tudom, milyen eszközt hazsnálsz, de java-s dolgokra ritkán nyomnak olyan pecsétet, hogy rad. a build, clean, deploy, appserver start időt, processzort és memóriát igényel.

egyébként win vagy lin alól nyomod?

ha win alól, akkor lőjj ki minden mást a memóriábólm, ne futtass ilyenkor semmi szemetet. vedd nagyobbra és állandó méretűre a swap-fájlt, rakd a boot volumetól különböző, ntfs-es volumera, használj egy rendes töredezettségmentesítőt, a nem használt dolgokat uninstalld, stb.
válasz

5) XYBeR
Egyébként a java-t ne szidjátok, rendkívül kellemes környezetet biztosít. A fejlesztők egy részének legalábbis ;-) Aki meg ne akarja, ne használja. Ha meg átmenetileg muszáj, akkor tűrj. A tűrés megtanulása fontos egy ember életében.
válasz

6) benczurzs
2 perc ? az nem is rossz, most gondold el ugyenezt, 800Mhz + 256 MB rammal, a fordítás kb 10 -15 perc Mielőtt bárki kérdezi sulis gépek.
Aztán így írjon az ember ZH-t
válasz


8) XYBeR
bakker, ilyen esetben miért nem ide-n kívül fordítotok és deployoltok?
válasz

9) Tamás
XYBeR, XYBeR: tényleg csak átmenetileg muszáj (választhattam, hogy J2EE vagy .NET, és mivel a .NET Linux alatt nem igazán vert gyökeret (nem biztos, hogy a tanár repesne az örömtől, ha Mono alatt csinálnám a házit), maradtam a J2EE-nél). De ez a plusz fél giga memória akkor is durva, fél giga memórián prímán futtatunk idegsejtszimulációkat többkompartmentes modellekkel különösebb erőforrás-problémák nélkül (pedig az se egy nagyon memóriatakarékos feladat), nemárhogy egy Hello World-ot ennyi ideig tartson lefordítani... Jó, elfogadom, de furcsa. Ilyenkor elgondolkozok, hogy vajon milyen gép ajánlott egy nagyobb projekt zökkenőmentes Java-s fejlesztéshez (például egy iWiW összedobásához), és hogy a sok reusability, scalability meg encapsulation kulcsszavak között hogyan veszik feledésbe szép lassan az optimisation meg az efficiency.

Egyébként Linux alól futtatom, a swap fájl mérete állandó (mivel swap partíciót használok, az is fél giga), és nem futtatok mellette semmi mást, még a Rhythmboxot is kilőttem, mert akadt az MP3-lejátszás fordítás közben Valószínűleg sokat spórolhatnék azzal, ha a NetBeans IDE helyett valami normális konzolos IDE-ben szerkeszthetném a forráskódot, csak őszintén szólva sejtelmem sincs róla, hogy hogyan lehetne konzolból deployolni, és időhiány miatt nem is most fogom kideríteni...
válasz


11) Pas
Java lol. . nézd meg az iWiW-et, ott az a rahedli szerver.. majdnem meghalt, amíg T alá nem pakolt még egy rakást. Ezzel szemben ott a myVIP, valahogy műűködik, és nem valószínű, hogy java-s ;] phpinfo() - php 4.4.2 mondjuk vannak ott jelek egy Tomcat-ra is (azaz Java-s cuccokra..) de Apache - Tomcat nem hiszem, hogy olyan jól bírná a terhelést, mint egy apache - php -mysql trió. És ugye myVIP nél kb 2-3 hét volt a felfutási időszak (1000-10 000-40 000-100 000-400 000 user) ennyi idő alatt persze be lehet operálni még pár db slave-t, app servereket.. stb, de minden flottul ment, nem úgy mint iwiw esetén..

Btw, ennyire nem gondoltam volna, hogy dúúrva ez a java előfordítós móka.. egyből gépi kódot szül, vagy mért ilyen lassú? :o (de még ha azt is csinálná.. 2 perc. az keggyetlen..)
válasz

12) Tamás
Pas: nem biztos, hogy helytálló a myVIP vs iWiW összehasonlítás, feltehetőleg utóbbinak még minimum egy nagyságrenddel több felhasználója van, de sajnos egyikre sincsenek konkrét adataim. Toy benchmark tesztek azt mutatják, hogy a JSP semmiben sem marad el a PHP-től (pl: Resin: JSP vs mod_php vs mod_perl ), de szerintem arra még senki nem vette a fáradságot, hogy ugyanazt az éles alkalmazást megírja JSP-ben és PHP-ben is, és akkor persze még mindig ott van a kód karbantarthatóságának / átláthatóságának a kérdése, amiben érzésem szerint a Java talán jobb lehet.
Egyébként meg sejtelmem sincs, mit csinál a Java a fordítás során, a .class fájlok csak Java bytekódot tartalmaznak, de azt elképzelhetőnek tartom, hogy az alkalmazásszerver a .class fájlok gépi kódú formáját cache-elve tartja, de hát ugye a PHP acceleratorok is ugyanezt csinálják. Viszont pl Pythonból is lehet bytekódra fordítani, és a Python fordító nagyságrendekkel gyorsabbnak tűnik nekem, mint a Java fordító.
válasz

13) Haszprus
Pas
de minden flottul ment, nem úgy mint iwiw esetén..
leszámítva hogy a myvip az indítása utáni második naptól kb. egy hétig eléggé halott volt, én meg is untam a belépési kísérleteimet (háttérinfó: a myvip az első napon úgy kezdett el működni, hogy mindent egy szerver végzett, nem volt még szétosztva. hogy az indulás utáni napokban is ez volt-e a helyzet, azt nem tudom.)
Tamás
nem biztos, hogy helytálló a myVIP vs iWiW összehasonlítás, feltehetőleg utóbbinak még minimum egy nagyságrenddel több felhasználója van,
600e iwiw vs 400e myvip, de nem ez a lényeg hanem hogy hány lapot töltenek le erről viszont nincs adatom.
válasz

14) Denes (nem regisztrált)
A webaudit.hu szerint majdnem 3x annyi oldalletöltés van az iwiw-en, mint a myvipen.
válasz

15) Haszprus
Köszönöm. Ez azt a teóriát látszik alátámasztani hogy a myvipre az emberek csak beregisztrálnak aztán mennek is tovább De jól szétoffoltuk ezt a topicot
válasz

16) Pas
Példának jó volt
Biztos vannak nagy és okos Java guruk, akik tudják mért tart sok sok százezer miliszekundumig ez a kis fordítgatás, ami ugye gépi időben nagyon sok
válasz

17) Tamás
Pas: nem gépi időben sok, hanem az én emberi időmben, mert lassan nyakamon a határidő
válasz

18) atleta (nem regisztrált)
Mit ertesz j2ee+JSP alatt? (A j2ee melyik reszeit hasznalod?) Es miert nem inkrementalisan forditasz? Ha sokat swappel a geped, akkor alapvetoen minden lassu lesz rajta, nem csak a java forditas. Amugy a java forditas nem lassu, pl. a C++-hoz kepest kifejezetten gyors. Jo build scripttel (inkremenatlisan forditva) par masodperc. A 2 percben biztos, hogy nem csak a forditas, hanem egy komplett build van, feltehetoleg WAR/EAR archiv generalassal, plusz esetleg deploymenttel, illetve alkalmazas szerver ujrainditassal (ami viszont termeszetesen eleg lassu dolog, meg akkor is, ha csak a tomcat-et restartolod).

Ismerni kell az eszkozoket, amiket hasznalsz. Egy sima hello world java program kb. 0 ido alatt fordul (es ebben benne van. hogy a fordito is behuz es elindit egy java VMet) az altalad leirt konfiguracion. A memoria igenyre visszaterve - meg kene nezni, hogy az IDEd mennyit eszik (egy NetBeans vagy egy Eclipse konnyen elmegy 160M-ig, ha abban van a web server meg esetleg az alkalmazas szerver is, akkor nyugodtan hozzaadhatsz meg 100-150M-at, a FireFox hosszu hasznalat utan siman felkuszik 200M-ra). Aztan a HelloWorld-bol tul messzemeno kovetkezteteseket eleg nagy butasag levonni: egy igazi (EJBs) J2ee alkalmazasnal eleg nagy az indulo 'koltseg', ami akkor is annyi, ha helloworld-ot irsz, meg akkor is, ha egy banki alkalmazast. Vagyis pont a hellowroldbol nem lehet semmilyen kovetkeztetest levonni.

A PHP-s buta flame-eknek meg azert nincs ertelme, mert a myvip lehet kiraly, de a wiw az abszolut gaz. Ahogy az is, hogy aprilisban kepesek voltak eloadast tartani es cikket irni a horizontalis skalazhatosagrol (most nezem a cikket ). Attol, hogy valami pont javaval csinaltak meg szarul, attol meg nem a java a szar, hanem mondjuk igen nehez ilyen terhelest elbiro alkalmazast irni (bar a j2ee jol skalazodik, de a fene se trudja, hogy a wiw j2ee szervereket hasznal-e). A tomcat csak egy referencia implementacio, vannak lenyegesen gyorsabb servlet containerek is. Az, hogy a php+apache gyorsabb-e, mint a tomcat egyebkent teljesen lenyegtelen, mert a tomcat itt csak egy frontend szerver (a megjelenitest vegzi) a lenyegi munkat a mogepakolt alkalmazas szerverek vegzik. Es ha rendes j2ee alrchitekturat hasznalnak a sracok, akkor egyszeruen csak ra kell dobni meg egy gepet. Tudatlan vagyok PHP ugyben, de nem nagyon hiszem, hogy tamogatna clusteringet. Akkor viszont nezhetsz butan, amikor elfogyott a legerosebb megveheto gep szamitasi teljesitmenye is.
válasz

19) atleta (nem regisztrált)
Na, vegigneztem a wiw-es prezit. Hat egyreszt Tomcat-et hasznalnak (ami nyilvan nem a leggyorsabb), masreszt csak Tomcatet hasznalnak (vagyis semmi alkalmazas szerver nincs annak ellenere, hogy folyton arra hivatkoznak), semmi EJB, amit pont a skalazhatosag miatt talaltak ki. Persze lehet, hogy az EJB nem birna ezt a terhel;est, de akkor is illene mogottes alkalmazas szerverek pooljat hasznalni (mondjuk a JavaSpaces-ben ez pont allatorvosi lokent hasznalt altalanos pelda), az adatbazist meg mondjuk csak backupnak hasznalni. (Adatbazis tulterhelesre is panaszkodnak, az pedig Oracle, es meg egy szuper php-s megoldas eseten is kene - sot, ott ugye mindenkepp kene.)
válasz

20) Tamás
atleta: J2EE+JSP = jelen esetben van néhány enterprise bean-em, amit egy JSP-s webkliensből b*szogatok. A bean-ek közül néhány container managed persistence-szel rendelkezik és egy Derby adatbázisba pakolja magát. Nem egy nagy kaland, az egyik tárgyból házi feladat, és az előadó szerint 20 óra munkánál többet nem kéne belefektetni, de a villámgyors fordítás miatt én már lassan 50-nél járok
Ha az inkrementális fordítás alatt azt érted, hogy csak azokat a .java fájlokat fordítom újra, amelyek változtak, akkor azt használok, pontosabban a NetBeans gondolom így dolgozik. Nagyon ajánlom neki, hogy így dolgozzon.
Most éppen három és fél perc a build, plusz igen, pongyolán fogalmaztam, ebben benne van a WAR-EAR buildelés is (amin nem értem, mi tart eddig, tudtommal a JAR formátum a ZIPre épül, azt meg pillanatok alatt meg lehet csinálni), illetve az undeploy-deploy kör is. Az alkalmazásszerver szerencsére nem indul újra. De volt már olyan, hogy fordítás közben a NetBeans azt mondta, hogy timeout, ilyen sokáig nem lenne szabad fordulnia
Memóriahasználat: a top szerint a NetBeans eszi most a memória 37%-át (768 Mbyte a teljes, tehát a virtuális+fizikai memória), az alkalmazásszerver a 34%-át, a Firefox 5-öt.
Legszívesebben kidobnám a NetBeans-t a francba és vim-mel szerkeszteném a forráskódot, csak konzolból egyelőre csak homályos sejtéseim vannak, hogy hogyan megy a build meg a deploy, és időm meg nincs kideríteni, sajnos Mindenesetre úgy veszem észre, hogy oké, hogy a J2EE szép skálázható meg minden, de ahhoz, hogy emberi tempóban fejleszthess alatta, atomerőműnek kell lennie az asztalodon, nem egy szimpla notebooknak. És ilyenkor persze reflexből sírok, hogy a Linux kernel gyorsabban lefordul a gépemen, mint az én kis szar házifeladatom
A PHP egyébként tényleg natív módon nem támogat skálázható architektúrákat, de azon gondolkoztam, hogy a load balancing ott is roppant egyszerűen megoldható: fogsz négy-öt szervert, felrakod rá a PHP alkalmazásodat (mindre), aztán eléjük pakolsz egy frontend szervert, ami mindig ahhoz a géphez továbbítja a kéréseket, aminek épp a legkisebb a load-ja. Nem próbáltam még ilyet élesben, de nem hiszem, hogy túl bonyolult lenne megvalósítani.
válasz
Hozzászólásod:


Nem vagy bejelentkezve, de...

A)
hozzászólhatsz regisztrálatlanul...

B)
ha regisztrálva vagy, bejelentkezhetsz...