Portál AbcLinuxu, 25. dubna 2024 07:52
Populární služba NAVRCHOLU.cz prošla loni zásadním vylepšením. V tomto rozhovoru její autor Michal Krause popisuje architekturu i důvody, proč opustil PHP.
Leoš Literák: Původní navrcholu.cz bylo napsáno v PHP. Jaké jsi měl důvody, že jste druhou verzi psali v Javě?
Michal Krause: Nejdříve malé upřesnění: původní verze byla napsaná z části v ANSI C (počítací server) a z časti v PHP (frontend).
Backend měl velkou výhodu v rychlosti, ale vývoj byl relativně pomalý a doslova peklem se ukázalo být ladění. Hledat chyby, které nastanou třeba jednou za sto tisíc zcela různorodých a v zásadě nesimulovatelných požadavků, a to navíc v multithreadové aplikaci psané v C, se mi jeví být takřka neřešitelným problémem.
Volba PHP pro frontend přinesla zejména jednoduchost a rychlost vývoje, ale zásadním problémem se ukázaly být zcela nekontrolovatelné a nepředvídatelné paměťové nároky. Neznám bohužel vnitřnosti PHP, ale z praxe se mi zdá, že režijní náklady jsou příliš vysoké. Ještě o něco starší verze NV měla i frontend napsaný v C (CGI skripty), takže jsem mohl docela dobře srovnávat shodné programy napsané v obou jazycích. Ukázalo se, že na to, co jsem v C zpracoval zhruba ve 2 MB paměti, potřebovalo tehdy PHP neuvěřitelných 64 MB.
Je to už delší dobu a lecos se mohlo v nových verzích zlepšit, ale i dnes při vývoji jiných projektů v PHP narážíme na vysoké paměťové nároky. Zní to trochu paradoxně, protože Java má pověst paměťového "nenažrance", ale režijní náklady na paměťové struktury se mi zdají být nižší a její nároky jsou z mého pohledu především předvídatelnější a do jisté míry kontrolovatelné.
V neposlední řadě bylo zbytečně komplikované psát backend a frontend v různých jazycích, protože to obnášelo částečné duplikování kódu.
Když jsme si tedy tohle shrnuli, začalo zkoumání konkrétních možností - například jsme potřebovali bezpodmínečně podporu jaderných vláken kvůli využítí více procesorů, podporu asynchronních nebo neblokujících IO operací atd. - a pochopitelně i testování výkonu. Java splnila všechno potřebné a tak vyhrála výběrové řízení :).
LL: Jaká byla úroveň tvých znalostí Javy, než jsi začal přepisovat navrcholu?
MK: V Javě jsem krátce programoval odhadem tak okolo roku 1997 nebo 1998. Pak jsem se delší dobu věnoval jiným jazykům a vrátil se k ní až kvůli tomuto projektu, tedy asi v polovině roku 2002. Musel jsem si samozřejmě lecos oživit a hlavně se seznámit s dostupnými knihovnami a podobně, ale v zásadě to šlo celkem hladce.
LL: Narazil jsi v průběhu vývoje na zásadní problémy, kvůli kterým jsi pochyboval o správnosti rozhodnutí zvolit Javu?
MK: Neřekl bych - na problémy jsem samozřejmě narážel, ale nikdy nešlo o nic tak zásadního, že bych litoval své volby. Jistě, umím si představit mnohá vylepšení, která by programátorovi usnadnila život, ale jsem přesvědčen o tom, že podobné by to bylo nezávisle na výběru jazyka. Na druhou stranu ovšem musím říct, že kdyby v době našeho rozhodování neexistovala verze 1.4 (mimochodem, teprve relativně krátce), asi by to dopadlo všechno trochu jinak.
LL: Jak se na tuto volbu díváš s odstupem několika měsíců od nasazení nové verze?
MK: Jak jsem řekl, nemám žádný důvod litovat, takže jsem v zásadě spokojen. To už mám spíš drobné pochybnosti o některých implementačních záležitostech, ale to je asi normální - člověk se stále rozvíjí a s ročním nebo dvouletým odstupem už na některé věci zkrátka nahlíží jinak :).
LL: Prozradíš nám něco o architektuře NAVRCHOLU? Jak to uvnitř funguje? A jaké Open Source komponenty či knihovny používáš?
MK: Měření je realizováno vlastní implementací HTTP serveru, který je samozřejmě výrazně jednoúčelový. Jeho úkolem je "jen" prostý sběr dat, na která pak čeká agregátor. Ten generuje výsledky, které nakonec v různých pohledech mohou uživatelé vidět na webu. Protože při testech se databázové servery, které jsem zkoušel, na obdobné objemy dat netvářily zrovna optimálně, nakonec jsme si napsali i vlastní úložiště - samozřejmě opět jednoúčelové.
Webové rozhraní je realizováno pomocí servletů běžících pod Tomcatem.
Pokud jde o knihovny, zmínil bych například Log4j, Lucene, Freemarker, Proxool, Hibernate nebo Dom4J. Našlo by se ještě pár dalších, ale tyhle bych rád zdůraznil, protože je považuji za mimořádně povedené a hodně mi ulehčily práci.
LL: Jaké stroje používáte pro příjem dat, jejich zpracování a webové rozhraní? Jak jsou dimenzovány a jaký mají load?
MK: Backend, který v součastnosti realizuje sběr i agregace dat, je rackový Sun s dvěma procesory Xeon 2,8 GHz a 2 GB RAM. Jeho obvyklý load se pohybuje okolo 0,60. Frontend je pak 2x Pentium III 1 GHz s 768 MB RAM. Jeho load je za normálních okolností také někde okolo 0,5 až 0,6.
LL: Běží pod Linuxem? Jaké máte jádro a souborový systém?
MK: Oba běží pod Linuxem. Jádro na backendu je 2.6 a na frontendu 2.4 - to proto, že nejsme schopni zaboha uchodit stabilně síťové sdílení disků při kombinaci 2.6<->2.6. Přitom je jedno, zda se používá NFS či SMBFS - v obou případech dochází při zátěži k rozpadávání spojení a někdy až k vytuhnutí stroje. Pokud je na klientovi jádro 2.4, běží tatáž konfigurace naprosto v pohodě, problém je opakovatelný i na jiném hardwaru. Takže bych tak trochu tenhle rozhovor zneužil pro dotaz k ctěnému čtenářstvu, jestli náhodou někdo nezná řešení :).
Pokud jde o souborové systémy, přecházíme kvůli opakujícím se problémům z ReiserFS na XFS, zatím k plné spokojenosti. V současnosti je to zhruba půl na půl.
LL: Jaké je heslo na roota?
MK: Ha ha :)
LL: Myslíš, že serverové aplikace psané v Javě jsou výkonnostně srovnatelné s aplikacemi psanými v céčku?
MK: Já jsem nedělal žádné sofistikované testy, takže nechci rozhodně vynášet nějaké konečné soudy. Ale konkrétně v našem případě jsem měl k dispozici reálnou, takřka shodnou aplikaci napsanou v obou jazycích a rychlost byla v podstatě totožná. Myslím si, že HotSpot kompilátory v posledních verzích Javy opravdu odvádějí skvělou práci a na výkonu je to znát.
Na druhou stranu jsou ale oblasti, kde rozdíl mezi javovou a céčkovou aplikací vnímám celkem silně, a to třeba u desktopových GUI aplikací - pravda ale je, že pracuji převážně na počítačích, které z dnešního hlediska mají svůj zenit už dávno za sebou (abych byl konkrétní, vcelku spokojeně a bez větších obtíží jsem do tohoto týdne používal počítač s procesorem PIII 450 MHz :).
LL: Jaké vývojové prostředí používáš?
MK: VIM :)
LL: A co ROOT? Plánuješ jej také převést na Javu? ;-) Kdy nasadíte nový redakční systém a na jaké novinky se můžeme těšit?
MK: ROOT v Javě určitě napsaný nebude, protože bude využívat stávající redakční a publikační systém. Termín po mně nechtěj, dle Murphyho zákonu znamená jeho zveřejnění v podstatě absolutní jistotu, že se nestihne :).
Z obdobného důvodu bych si rád nechal pro sebe i většinu novinek, protože ještě stále probíhá vývoj, ale určitě bude nový design, mohu slíbit propracovanější vyhledávání, lepší diskuze či detailnější a doufejme přehlednější členění článků do rubrik. Na to ostatní si budeš muset Ty i čtenáři ještě chvíli počkat :).
Zajimalo by mne par cisel (na ktere se celkem nepochopitelne LL nezeptal...) pokud nejsou tajna: pocet requestu za den, ve spicce a pripadne rozlozeni z hlediska agregace (teba 1% ze vsech sledovanych serveru dela 90% requestu apod.) a celkovy pocet sledovanych serveru. Bez alespon techto cisel si clovek tezko udela predstavu.
A dalsi vec je skalovatelnost, lze to rozlozit na vice stroju (nejen DB a ostatni, ale treba i samotny agregator na vice masinach apod.)?
Jinak pokud duvodem k pouzivani NFS/SMB je sdileni DB tak mi to pripada jako hodne sverazne reseni.
Samozrejme, pokud bych v C++ udelal new() na kazdy objekt zvlast, budu mit stejnou spotrebu jako javovsky vector, ale proc bych to delal kdyz mam STL vector?Muzu se zeptat, cemu pripisujete vetsi spotrebu pameti? Je to vetsi rezii datovych objektu nebo tim, ze u Javy lezi v pameti pomerne dost mrtvolek?
tot vecne dilema.
Schvalne srovnejte pocet utoku pres stack overflow na javove a C aplikace.
Az to Sun zoptimalizuje tak, ze start desktopovych aplikaci nebude vice nez o 20% pomalejsi nez nativni aplikace, tak to bude prulom javy i na desktop. Uz ted pouzivam denne nekolik GUI aplikaci v jave a takove IDE, to je pekny bumbrlicek Zvlaste kdyz mate projekt s tisici tridami.
, radsi zustanu u oskliveho vimu
29.11.2004 21:31
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
Tym narazam na x verzii prekladaca Cka, exoticke OS dependent kniznice ala VCL a podobne. Samozrejeme pripustam, ze v jave je tiez mozne takto orientovane aplikacie/kniznice vyrabat, no pri beznych veciach ako GUI, sockety, File access, DB access a podobne sa to nedeje. Ak si ale spomeniem na autoconf madness - myslim, ze je to naozaj niekde inde
Urobia si klbko strong referencii, ktore GC len ztazka rozmota a mame to... Ale aj tu je treba jazyk poznat, pripadne mat "spravny" navrh, ale to je uz o ludoch, ktori ho pouzivaju (WeakReferencie)
Java je ve vyuzivani pameti naprosto neefektivni...Zalezi jak na co. JRE samozrejme uz umi recyklovat objekty a podobne finty. Nekdy se GC muze i hodit a urychluje beh aplikace - zejmena jeji ukonceni. Proste to co jste napsal neplati vzdy. Urcite neni zcela spravne vytvoret hloupe 50 tisic objektu. Jak jste podotknul, neni to vhodne ani pro C++, natoz pro Javu. A uz vubec nechapu, co se snazite resit pomoci kontejneru Vector, ktery je pochopitelne i v Jave. Jestli myslite nejakou linou inicializaci, tak tim se nic neresi. Nerelevantni je tvrzeni, ze se (Java) proste neda srovnavat s aplikacemi, kde se vytvori statisice objektu. Java je objektove orientovany jazyk, proste se v ni vytvari tisice, desetitisice i statisice objektu. To je proste tak. A ze i velike programy jsou dnes napsany v Jave (nejen CAD, hry nebo databaze) je myslim kazdemu jasne. Doporucil bych Vam nejakou knihu o optimalizaci Javy, nez zacnete "srovnavat". Zacit muzete manualovou strankou JRE, protoze staci napriklad jen par parametru (nastavit spravne HEAP) a ejhle -- neswapuje to. A kdyz mate zkusene programatory, kteri vedi, jak programovat (v Jave), muzete se pustit bez starosti i do nejakeho CADu.
Ad: STL Vector versus Java Vector: U STL vectoru vyuziti pameti rovna se velikost objektu * pocet objektu (+-). U Java vectoru kazdy objekt se alokuje zvlast takze je to stejne (jak jsem uz psal) jako kdyby STL udelal pro kazdy objekt new(). V praxi to znamena mnohonasobne vyssi vyuziti pameti.Prominte, ale stale tomu nerozumim. Mohl byste to vysvetlit podrobneji nebo me odkazat na relevantni zdroje? Uplne presne si uz nevybavujju, jak funguje STL Vector, ale z Vaseho prispevku predpokladam, ze pri vzniku instance Vectoru alokuje jiz nejaky prostor a v nem vytvori nekolik (napr 50) instanci pozadoveneho objektu. Ale to znamena, ze jsou objekty ve Vectoru ulozeny hodnotou a to s sebou nese jiste problemy pri pridavani. Druhou moznosti, jak si drzet objekty ve vektoru, je pamatovat si na ne odkazy. To s sebou nese jistou pametovou rezii: tak 2B na odkaz + nejaka mala rezie, ktera bude po rozpocitani na jednotlive prvky vektoru asi tak desetina bitu (nebo min, zalezi na poctu prvku a implementaci). Stale tu ale nevidim souvislost pametove narocnosti s vytvarenim objektu pojednom vs. en bloc. Muzete mi to prosim objasnit? Jinak s Vami souhlasim, ze mit aplikaci s 50 * 10^3 objektu je celkem normalni. V takovych aplikacich je vsak relativne malo typu objektu. V tom pripade je mozne tyto objekty recyklovat misto mazat a znovu vytvaret. Jiste je to prace navic (pokud to jiz nepodporuje VM), a v tom pripade je na zvazeni, zda je pracnejsi obejit se bez vymozenosti Javy nebo muset delat v Jave vlastni recyklaci. Co se tyce poctu programu typu GIS, CAD, ale i office napsanych v jave: myslim, si, ze Java je z pohledu techto programu velmi mlada -- v tom smyslu, ze zacala byt pro tyto ucely pouzitelna teprve pote, co tyto programy meli za sebou jiz nekolik uspesnych komercnich verzich (a jsou tedy napsany napr. v C). Firma, ktera vyrabi takovyto software pak musi nutne zvazit, jestli ji prepsani programu do Javy prinese vic vyhod nez nevyhod. Znamena to totiz, ze se nejakou dobu nebudou pridavat nove funkce, ze je potreba preskolit programatory, kteri pomerne dlouho dobu nebudou mit v Jave takovou vykonnost jako v C, prijmout nove programatory misto tech, co firmu kvuli jave opustili, a zaskolit je ve firemnim know-how. Prepracovat/koupit podpurne a vyvojove nastroje. A co je ze vseho nejhorsi, ze prepisovanim se nutne zavlecou nove chyby, ktere bude nutne odstranit. Osobne se tedy domnivam, ze prevedeni komercne uspesneho a rozsireneho programu z jednoho programovaciho jazyka do druheho se pohybuje na hranici pricetnosti. Proto IMHO mame tak malo programu v Jave.
kym v JAVE nemam inu moznost ako pouzit referencie. (neuvazujem ako pouzitelne nieco take: String.getBytes()...)
.
Jsem sice C/C++ a javu nehanim ale proste vidim urcite jeji slabiny na druhou stranu ma spoustu plusu.
Cau.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
2.12.2004 15:29
7.12.2004 13:29