Nové jetty, nové fórum (diskuse)

[Käyttäjä 11133]

Hlavně ať je na viditelném místě toho fóra odkaz na Linuxové instalatéry. Jinak dobrá práce. Moc si cením toho času co ABCLinuxu věnuješ ty a všichni ostatní.

[lol]

lol, nasadit na ostrym serveru neozkousenou verzi a pak se modlit at vyjde jakesi RC :-/ to je ta supadupa vyhod lunetixu na serveru...

[Věroš]

Jojo a jsou i tací lidi, kteří v ostrém provozu používají software s menší verzi než 1.0, k tomu RC verze jiného softwaru, nacházejí tam chyby a reportují je. A ty chyby se světe div se, skoro samy opravují a propagují do celého světa.

Na možnost najít a opravit si chybu ve zdrojáku si člověk strašně lehce zvykne a pak už není cesty ven.

---

PS: Nekrmte troly, já vím. Ale když mě to nedalo.

[Käyttäjä 11133]

Ono to bude asi tím, že straší jetty měla jiné nepříjemné bugy.

[Filip Jirsák]

To, že jste tu verzi nezkoušel vy, ještě neznamená, že je nevyzkoušená Modlit se, aby vyšla RC verze taky nikdo nemusel, zkompilovanou verzi schopnou nasazení na server jsem měl samozřejmě pár minut po vyrobení toho patche. Čas mezi opravou a vydáním RC verze se právě dá ideálně využít k testování.

Spousta chyb se i při sebelepším testování projeví až v ostrém provozu, v testovacím provozu těžko nasimulujete tisíce přístupů denně a to, že ty stránky někdo opravdu čte. Té chyby se zdvojováním písmen by si buď někdo musel všimnout ve zdrojáku, a nebo si jí musel někdo všimnout na stránce. To se při testování podaří jen těžko, protože nikdo nebude pročítat při testování všechny texty, jestli tam náhodou něco není špatně. K té chybě docházelo pouze v případě, že u 2048 bytů dlouhého bufferu vyšel zápis vícebajtového znaku UTF-8 přesně na konec bufferu (tedy znak se ještě vešel, ale nezůstal za ním volný ani bajt). Jaká je pravděpodobnost takové chyby si můžete spočítat sám.

Mimochodem, být to ještě před čtvrt rokem, testoval bych Jetty na Windows a ta chyba by se tam projevovala úplně stejně…

[User682]

zdravim,

add vykon:

Nevim, zda je problem na strane aplikace nebo database, ale zkuste tyto figly: Plati anebo, ne jako poradi za sebou.

0) vydumpovat databasi jako skript a nadumpovat ji zpet. pripadne setridit zaznamy nejakym sortem. Plati v pripade, ze jste s databasi nejak dlouho nehybali.

1) hodit vice pameti na indexy a pripadne pro databasi v databasovem serveru.

2) vytvorit indexy stylem:

create index name on table(sloupec) order by id desc. Nevim, zda to vase verse mysql jiz umi.

pripadne sql prikaz reindex se obcas hodi do cronu.

Precijenom pristupujes k zaznamum nejcasteji od nejaktualnejsiho.

4) Zkuste pripadne javu 1.6. vykonove je jinde. Co jsem ted zkousel jboss behem par dnu, tak bezi uplne jinak.

Dejte vedet, jak to dopadlo.

bye gf

[Leoš Literák]

Diky za pripomenuti, muzeme zkusit mysql optimize. Nicmene podle top zabira vetsinu procesoru java, ne mysql. Indexy mam snad vsude, kde to dava smysl.

Java 6 je vyrazne rychlejsi? No, nastuduji si, co je v ni noveho, otestuji ji doma a pak provedeme upgrade i na serveru. Jsem zvedav.

[Zdeněk Burda]

Nová java je skutečně znatelně rychlejší, za zkoušku to stojí.

[Leoš Literák]

Je treba nastavit nejake JVM argumenty nebo postaci klasicke -server -Xmx -Xms?

[Filip Jirsák]

O žádné novince, kterou by bylo nutné zapínat nějakým přepínačem, nevím. K rychlosti přispívají úpravy přímo v kódu JVM, ty asi nejde měnit přepínači, nové NIO založené na epoll je v Javě 6 defaultně zapnuté (zapnout se musí v Javě 5), JMX agent pro sledování JVM je pro lokální použití také rovnou defaultně zapnutý (v Javě 5 se musel zapínat). O ničem jiném nevím.

Asi by stálo za to nakonfigurovat JMX tak, aby na něj šlo přistupovat s heslem nebo certifikátem vzdáleně třeba přes jconsole, např.

java -Dcom.sun.management.config.file=jmx.properties  \
 -jar start.jar etc/jetty-jmx.xml etc/jetty.xml

#jmx.properties
com.sun.management.jmxremote=true
com.sun.management.jmxremote.port=…
com.sun.management.jmxremote.ssl=false
com.sun.management.jmxremote.authenticate=true
com.sun.management.jmxremote.password.file=…
com.sun.management.jmxremote.access.file=…

Viz Monitoring and Management Using JMX Technology.

[xvasek]

Mně zase připadá, že s rychlostí problém - od upgradu na toho Suna - není...

[zde]

<flame>Hmm, a co kdybyste to z Javy přepsali do něčeho o chlup méně pomalého, třeba PHP, Basicu, nebo BCPL </flame>

[trekker.dk]

V kterém Basicu? Ono jich bylo víc. Ale pokud se Leoš rozhodne předělat ábíčko do QBasicu, tak mu rád podám pomocnou ruku

[User682]

Indexy sice mas, ale tyu potrebujes sestupne indexy podle chovani vetsiny operaci. Ozkouseno na linuxsoftu.

S tim nacachovanim database a indexu jsem to myslel tak, ze pak ti nedochazi k efektu pumpovani pameti na urovni OS. Videl jsem na MSSQL a je to vcelku sranda, kdyz se preleva pamet mezi servrem, IIS a vyvojovym prostredim. Takze aplikace ti sice zerou treba 30% CPU vykonu, ale celkove je to line.

Java6 vyrazne rychlejsi, jak na desktopu, ale ted me prekvapil compiere server na jbossu. Sel jsem pri startu z 50 na 37 vterin. A celkove je to i sviznejsi a mam takovy pocit, ze nezustava viset nikde pamet a podstatne rozumneji se pamet alokuje. Rovnou to ozkousej, preklad na 1.6 Ti jede, uzijes si sice nejake warningy a podle me to pobezi. Maximalne bych si posilal objekty http pozadavku do souboru nebo na jiny stroj a tam to nechal bezet. Takto i odladit chybu nebo zatizeni. Sice lovis chybu v 200MB a vetsim souboru testovacich dat, ale jede to. Idealne logni veskere sql dotazy nebo pozadavky do souboru a pak si to pust a uvidis, ze mista pro optimalizace je skutecne dost.

Co se tyce znovu nahrani database, tak to je z duvodu, ze mas defragmentovana data ruzne na disku a ne vcelku. Samozrejme, ze kernel je v tomto "chytry", ale nekdy to chce tomuto pomoci.

bye gf

[Leoš Literák]

Nevim o tom, ze bych nekdy tridil data podle id. Vetsinou tridim podle datumu nebo netridim vubec.

[User682]

OK, dopln trideni treba podle datumu nebo ID. id bylo brano jako priklad. Pointa je v tom, ze ty vetsinou data podle nejnovejsiho.

bye gf

[Filip Jirsák]

Verzi, která by to ASC/DESC u indexů rozlišovala, asi ještě nemá nikdo

MySQL 5.1 Reference Manual: An index_col_name specification can end with ASC or DESC. These keywords are allowed for future extensions for specifying ascending or descending index value storage. Currently, they are parsed but ignored; index values are always stored in ascending order.

Navíc mi uniká, k čemu by informace o vzestupném nebo sestupném řazení měla být indexu dobrá, nenapadá mne žádný druh indexu, kde by se to uplatnilo (pro b-tree i hash tabulku je každopádně taková informace k ničemu).

[zde]

To že mysql bere málo CPU ještě neznamená že není úzkým hrdlem- pokud blbě cachuje bude si brát málo cpu, ale hodně iowaitu. Zbývá po Javě ještě něco CPU v idle?

[Leoš Literák]

Jakym zpusobem bych to poznal, ze mysql ma hodne iowaitu? CPU jede na 100%, java jej dokaze spolehlive zahltit.

[zde]

No, to je docela problém, prý příspěvky procesů do celkového iowaitu jde nějak zjistit přes inotify, ale jak přesně to netuším. Mě vždy stačilo že top ukazoval vysoký celkový iowait, a viník byl vždy jasný (rrdtool, apache, mysql..), protože na hostu víc než jedna i/o intenzivní aplikace neběží. Ale když jde cpu do plna tak snižování iowaitu stejně nepomůže, je bezpodmínečně potřeba nějak urychlit tu Javu- zkoušeli jste to nějak profilovat?

[Aleš Kapica]

V podstatě sis sám odpověděl "Linuxový rádce" mi přijde jako docela dobrý název. S trochou nadsázky mě napadlo pojmenování - taková parafráze na Nietzscheho - "Tak pravil guru.."

[Leoš Literák]

Mozna bych mohl vytvorit i wiki topic, kam by se lide mohli zapisovat s nabidkami pomoci. Stacila by jednoducha tabulka: jmeno, kontakt, mesto/oblast, preferovana distribuce. Teoreticky by to slo napsat jako priznak do profilu a tabulku generovat automaticky, ale kodovat kazdou "blbustku" se mi nechce

[Radek]

Jen k tomu foru. Cas od casu se vyskytnou ve foru otazky, ktere nesouvisi primo s linuxem (napr.: problem s hardwarem jako takovym) a ktere jsou pak uzamceny. Napadlo me, ze by misto uzamceni mohly byt adminy v systemu oznaceny tak (nebo primo vytvoreny v dane kategorii), aby nedochazelo k jejich indexovani a po case by byly vymazany. Tim padem by nezabiraly zdroje. Uzivatele by si mohli v profilu vybrat, jestli takove dotazy zobrazovat (pak by neomezovaly ani je).

Pisu to proto, ze ackoli je tento portal jednoznacne zameren, navstevuje ho spusta schopnych lidi, ochotnych poradit i v jinych oblastech. A pokud mam jednou za 1/2 roku problem, ktery by do teto kategorie spadal, prijde mi zbytecne se kvuli nemu registrovat na jinem portale, kdyz je odpoved casto trivialni...

Kazdopadne to byl je navrh, jinak dik za odvadenou praci.

[peterh]

Nerobil sa nahodou upgrade HW len nedavno? Da sa niekde zistit aku ma abclinuxu zataz? Celkom by ma to zaujimalo (hlavne koli jave ako technologii na web) - napr. pocet pristupov, pocet dotazov a take veci.
Ohladom linux guru - celkom dobry napad, ale podla mna je na to lepsi realtime chat (ako napr. udrzuje ubuntu a verim ze aj ine distribucie).

[Leoš Literák]

Awstats hlasi kolem 25 tisic visits, 150 tisic pages a 5 GB traffic za den. SQL dotazu mame mezi 15 az 20 za sekundu (silne cache). Load se od prosince pohybuje kolem 4-5, pred tim byl kolem 3 (jedna zmena v cachi a takovy dusledek). Server ma nejaky dual core athlon a par giga ram, presna cisla se daji najit v archivu clanku.

Ad chat - preferujeme data, ktera muzeme archivovat a pouzivat ve fulltextovem hledani. Aby byla uzitecna i dalsim lidem v budoucnu. To IMHO chat obecne nesplnuje.

[happy barney]

nehnevaj sa, ale tuná niečo smrdí, java nejava (okrem chýbajúcej dôležitej informácie o HDD)
nemienite prejsť na predgenerované stránky (resp šablóny?). Nebude to síce až tak online, nebude to brať do úvahy blokovanie užívateľov, ale budú to statické stránky bez prístupu do db ... (okrem insert stránok).
a btw, niečo sa mi zdá o ukladaní XML dát do db, používate to ?

imho, bez prekopania spôsobu práce s datami vám nepomôže ani nový hw. Som ochotný pomôcť s návrhmi, s sql, html, css. S javou možno časom, keď sa mi prestane nepáčiť

[Leoš Literák]

Ja vim, proto posledni dobou nedelam nove featury, ale zameruji se jen a pouze na optimalizace. Ale abicko je neskutecne dynamicke a plne funkci, proto je ale i narocne. Napriklad defaultni sablona je strasne narocna, bez ni mate vysledky okamzite. Zkuste si schvalne dat na konec url ?varianta=print.

Jenze v te sablone mame krome reklam i anketu s informaci o poctu komentaru, deset zpravicek s komentari, rozcestnik se ctyrmi servery, pracovni pozice atd. U toho vseho je pro prihlaseneho uzivatele nutne zjistovat, zda mu nepribyly nove komentare. Nastesti vsechny tyto informace jsou uz v cachi a nevyzaduji jediny SQL dotaz, presto zabiraji CPU. A predegenerace teto casti neni mozna, leda pro kazdeho uzivatele zvlast, a vyzadovalo by velmi narocny kod pro jeji invalidaci (pribude novy komentar u nektere zpravicky, jenze ktere cache mam promazat, kdyz kazdy uzivatel muze mit jiny pocet zobrazenych zpravicek).

Dalsim problemem jsou smajliky. Vazne uvazuju, ze nahrazovani za obrazky poslu do vecnych lovist. Pro kazdy komentar (ma-li je uzivatel povolene) musim udelat regexp, zda tam smajlik je a v tom pripade vytvorit stringbuffer, projit cely string a vytvorit novy. Toto je take dost narocna funkce. Mozna by to slo udelat jednou pri ukladani dat a vytvorit dalsi sloupecek s vysledkem, jenze nejdrive bych musel prevest vstupni data do HTML, protoze tato transformace je az druha v poradi. Nejdrive se totiz musi doplnit znacky <p>, pokud uzivatel pouziva prazdny radek pro odradkovani. Tohle doplnovani je stejne narocne jako smajlici a chtel bych s nim neco udelat, viz starsi blogy, kdy hledam solidni html parser. Odstranenim techto dvou transformaci vyrazne klesne vypocetni narocnost zobrazeni stranky.

Samotne XML neni problem, to uz jsem si kdysi meril. Kazdy objekt ma jen nekolik malo elementu a atributu, to parser ma za chvilicku hotovo. Problem byval, kdyz diskuse obsahovala kazdy komentar jako element. Nacist flame se sty komentari uz dalo zabrat. Ale tady jsem pridal novou tabulku a je klid.

Jak muzes pomoci? Skoda ze si netykas s javou, hodne by se mi hodila pomoc nekoho, kdo se kamaradi s profilery. Nicmene muzes se napriklad podivat na sqlka a indexy, zda tam neni mozne najit lepsi variantu. Taky by bylo fajn predelat CSS tak, ze budeme mit jeden styl s definicemi bez barev a pak dva dalsi styly, ktere jej importuji a nadefinuji jenom barvicky. Ted kazdou zmenu musime davat do obou CSS souboru a hrozi nesynchronizace. Taky by to ulehcilo vytvareni alternativnich stylu. Dalsi moznosti je predelat HTML/CSS tak, aby obsah stranky byl na zacatku a teprve za ni vetsina dat sablony (zpravicky, anketa atd). (tyto zmeny ale predem konzultovat s Robertem)

[Leoš Literák]

FYI: 1293 uzivatelu ma povolene emotikony, 311 zakazano, zbytek je ma zapnute by default

[Petr Zelenka]

Myslel jsem, že už v době, kdy jste nasazovali oficiální alternativní tmavý styl, tak Robert říkal něco o tom, že bude nová šablona Ábíčka -- taková, která bude lépe strukturovaná a takříkajíc CSS-ready. Jak to vypadá dnes?

[Leoš Literák]

Nejspise nijal, asi na to nemel Robert jeste cas.

[Lu-Tze]

Dalsim problemem jsou smajliky. Vazne uvazuju, ze nahrazovani za obrazky poslu do vecnych lovist. Pro kazdy komentar (ma-li je uzivatel povolene) musim udelat regexp, zda tam smajlik je a v tom pripade vytvorit stringbuffer, projit cely string a vytvorit novy.

Proč se to nedělá při ukládání komentáře? Do databáze bych si asi uložil původní surovou verzi příspěvku a jednotlivé verze s transformacemi (se smajlíkem, bez atd.).

[Leoš Literák]

Mozna by to slo udelat jednou pri ukladani dat a vytvorit dalsi sloupecek s vysledkem, jenze nejdrive bych musel prevest vstupni data do HTML, protoze tato transformace je az druha v poradi. Nejdrive se totiz musi doplnit znacky <p>, pokud uzivatel pouziva prazdny radek pro odradkovani. Tohle doplnovani je stejne narocne jako smajlici a chtel bych s nim neco udelat, viz starsi blogy, kdy hledam solidni html parser.

[Lu-Tze]

To je zajímavá odpověď na otázku "proč?". Inu, zřejmě si lepší nezasloužím

[Leoš Literák]

Predpokladal jsem, ze se me nekdo zepta proc, proto jsem rovnou v puvodnim komentari napsal i duvody, proc zatim ne. No a ty ses me presto zeptal

[Lu-Tze]

Tak asi mi to vůbec nepřišlo jako odpověď. A stále nepřijde. Nicméně dovedu žít s tím, že se to nedozvím

[Leoš Literák]

Ano, napadlo mne jiz davno, ze bych mohl cachovat finalni verzi. Jenze bych musel nejdrive vyresit prevod formatu rizeneho prazdnymi odstavci na HTML. V soucasnosti pouzivana verze je jen hack, ale nevadi mi, protoze se jeji vysledek nikam neuklada. Dale se mi nelibi, ze se zdvojnasobi pocet dat. Mozna bych musel delat i zmenu schematu, coz delam jen v nezbytnych pripadech.

[Filip Jirsák]

Možná proto, že by objem uložených dat pro diskuze vzrostl dvojnásobně? Bylo by nutné cachovat dvojnásobné množství informací?

[Leoš Literák]

disky jsou nejake SATA, nadupane SCSI by urcite byly lepsi.

[peterh]

No to neviem, nie su SATA ako SATA a nie je radic ako radic, ale verim ze tam nemate nejake desktopove disky...
Skor by sa mohla najprv vyskusat ta java 6, zevraj ma jemnejsie uzamykanie objektov, na dualcore by to mohla byt vyhoda. Ohladom profilovania - na strankach sunu som videl na to nejake pekne video (tusim cez netbeans).
Podla mna je prebehnutie toho textu a nahradenie linkami pre dnesne CPU nic, otazne je aky efektivny je ten regexp, ci sa musi ten StringBuffer zvacsovat alebo nie atd.
Btw. menilo sa nieco v poslednej dobe(vcera, predvcerom)? abclinuxu sa mi zda trosku rychlejsie. A okrem toho mne sa nezda vobec pomale, priemerne nabehne za 1,5-2s.

[peterh]

jo, este som zabudol, ked netreba synchronizovat StringBuilder by mal byt rychlejsi

[Leoš Literák]

Casto zkousim podezrele operace v mini testu, kdy zjistuji, kolikrat se dana operace provede za sekundu. Vetsinou jde o miliony ci statisice, takze nejake optimalizace nejsou nutne. Jenze i primitivni stringove operace preci jen nejaky cas zabiraji a jestlize jsou jich na strance treba desitky, muze se to nacist a pak treba jeden uzivatel musi o par desetinek sekund cekat dele.

Javu 6 jsem zkousel lokalne a muj LoadTest bezel dokonce o neco pomaleji nez s Javou 5. Navic reload classy zpusobil zamrznuti IDE na minutu, coz je docela otravne. Ale s tim si pohraju, zkusim nechat IDE bezet pod Javou 5.

Precti si blog, ke kteremu patri tato diskuse. Ten oznamuje nasazeni opravene verze jetty, coz melo mit za nasledek zlepseni odezvy.

Ad StringBuilder - diky za tip. Mrknu na nej a zkusim nahradit vsehcny vyskyty StringBufferu. Ty jsou vzdy pouzivany jen jako lokalni promenne v metodach, takze synchronizace je nezajimava. Pokud je tam skutecne vyznamny vykonnostni rozdil, pak me mrzi, ze tolik knihoven nepreslo na Javu 5 (treba konfigurovatelne).

[peterh]

No hej, uz ani neviem o com ten blog povodne bol .
Oni ani s javou 6 asi prechadzat nebudu musiet, pretoze implementovali escape analysis - detekuje ktore objekty su lokalne a podla toho by sa mali alokovat na stacku, ale zatial to pouzivaju vraj len na synchronizovanie (aspon to som o tom vygooglil). Ale stale maju v java api doc, ze stringbuilder by mal byt rychlejsi. Treba dat -server -XX:+DoEscapeAnalysis, ale mne sa nezda ze by to nieco zmenilo, ale tak ja to testujem na starte netbeans .
Inak teraz ma napadlo, ze skusim pozret firebugom ako sa to natahuje a skutocne samotna stranka je za 250ms (u mna), potom sa taha styl a s nim paralelne nic ine, skoro tak dlho ako stranka, potom obrazky a nakoniec sa dlho tahaju reklamne javascripty, neviem ci to tak taha firefox alebo kto komu co kedy posiela...

[peterh]

Dik, celkom slusne. Skoda, ze asi nikdy nezistime ako by boli na tom ine technologie.
Neskusalo sa to profilovat? Podla mna tomu novy hw nepomoze (no teda pomoze, ale na ako dlho?).

[Robert Krátký]

Založen bug:

http://bugzilla.abclinuxu.cz/show_bug.cgi?id=726