Zase jeden mirror (diskuse)

[doubleZ]

me zrovna spadnul net, takze jsem si niceho nevsiml

[Luk]

To už tu jednou bylo, ne? Zrovna VUT Brno, a zrovna v době špičky...

[Heron]

Asi jsem natvrdlej, ale k cemu je delat mirror verejneho webu???

[Michal Čihař]

Někteří lidi asi nechápou, že to není správná cesta, nebo jenom neumí zadat parametry stahovacímu nástroji. Tak jednou za měsíc se najde někdo, kdo mi stáhne celý můj web (resp. jeho prolinkovanou část) wgetem...

[Heron]

No ale ja se spis ptal na neco jineho. Nejak nechapu proc nekdo vubec ten mirror dela. Proste proc kopiruje k sobe verejnej web.

[Michal Čihař]

To taky nechápu

[unchallenger]

Nejspíš proto, že se off-line na ten veřejný web nedostane...

[Radomír Fojtík]

Muze to mit souvislost s "problematickym" prochazenim abicka Konqerorem? Vsiml jsem si totiz dneska, ze docela casto mi na cca 2-5 prohlizec nereaguje, kdyz se tady prochazim. CPU je po tuto dobu na 100% a okno Konqueroru se "neprekresluje".

[Radomír Fojtík]

2-5 sekund .. nebo tak nejak

[kavol]

Konqueror 3.4? - je nějaký bugový, při výpisu delší stránky (bez javascriptu, jen obsah adresáře s balíky generovaný squidem z ftp) mi "tuhne", překreslení okna s obsahem se koná asi tak na tři fáze, odezva na PageDown je tudíž klidně i kolem 10 s, než se to celé posune a překreslí, přepínání tabů i mezi okny Konqueroru není zrovna nejrychlejší, zátěž procesoru vždy vyletí na 100%, zatímco přepnutí do Konsole je okamžité, zpět do Konqueroru to trvá třeba 3 s apod.

[Radomír Fojtík]

Verze je 3.4, ale takove problemy ja nemam a pouzivam ho intenzivne (asi taky zalezi, kdo jake stranky s nim navstevuje). Ale zrovna dneska se mi to zdalo nejake "cudne" a to jen tady na abicku.

Asi takhle: Sleduji tema, prijde mail a kliknu >> zadrhnuti, po nacteni stranky prectu a klepnu na nejaky odkaz >> zase se to na par sekund zadrhne.

Pak prijde dalsi mail a kliknu >> a chova se to tak, jak jsem zvykly - normalne, plynule.

Proste zrovna dneska mi to tady chvilemi drhne, chvilemi zase ne. Vyckam a uvidim, jak se bude chovat dal.

[doubleZ]

mno, abych se pridal, tak bych chtel rici, ze na abicku jsem podivne chovani zaznamenal jen v jednom pripade, kdyz je bila volna plocha pod prispevky, jako treba tady dole, a do ni prazdne odklepnu kurzorem mysi ve firefoxu, tak skoci na konec stranky, trosku me to s..., protoze obcas chci klepnout, abych zrusil treba oznaceni atd a vadi mi, kdyz kliknu na volnou plochu kdekoli a skoncim najednou dole :)

[moira]

Nechapu, ze kdyz uz ma nekdo potrebu si udelat mirror proc to nedela

1. v noci
2. nema trosku slusnosti a neomezi pocet vlaken
3. nezepta se predem na svoleni

Bohuzel spouste lidi neco jako netiketa nic nerika :(

[David Jež]

Jee, koukam ze kolega spoluzak BSDckar je velmi popularni .
-djz

[Leoš Literák]

Dneska jsem zkusil zvednout pocet threadu jetty na 200. Ale nevsiml jsem si, ze by to pomohlo. Holt vyzkousim novou vetev, pouzita verze rady 4.1 je uz ponekud zastarala.

Nicmene vice si slibuji od zmeny v kodu. Ted kdyz si napriklad otevrete stranku, ktera neni nacachovana, tak pro kazdy objekt se spusti dva SQL dotazy. Pokud mate napriklad vypis fora s triceti dotazy, je to hned 60 SQL dotazu. Dovedete si predstavit, co to udela, kdyz nejaky neslusny mirror zacne tahat celou databazi najednou.

Optimalizace spociva v tom, ze se pokusim synchronizovat neprectene objekty ve dvou velkych SQL dotazech. Razem se zmensi slozitost z O(2n) na na O(2). A to by tedy melo byt znat. Mysql si oddechne a Abicko by mohlo slapat svizneji.

Snad to tento tyden zvladnu dopsat, akorat ocekavejte more chyb Unit test mam dle Test Driven Developmentu jiz hotov, ale urcite nepokryje vsechny varianty.

[manas456]

Nechci být příliš ofenzívní a chápu že tohle je volnočasový projekt atd bla bla bla, ale pokud web přestane fungovat při jednom vícethreadovém mirroru, tak je někde něco špatně.

A něco je špatně asi v kódu ábíčka, anebo v serverových aplikacích, které servírují obsah. Určitě není chyba v člověku, který mirror provádí. 97 spojení a load 30 NENÍ NIC!!!

Zkuste udělat někde testovací verzi, zkusit ji mirrorovat, postupně vyhazovat různé komponenty, třeba se postupně k něčemu prokousáte.

To je známý problém javy, také jsme to jednou museli řešit, větší zátěž nám bezpečně shazovala aplikaci. Stačí malé opomenutí a kód přestane být thread-safe, což při běžném provozu funguje a pak to při zátěži "náhodně" padá. Sám bych viděl problém asi tady. Vaše fascinace minimalizací SQL dotazů je zajímavá, ale tím to zřejmě není. Mirrorovací nástroj má vždy omezený počet threadů a čeká na jejich dokončení, takže při větším počtu SQL dotazů v kódu se odezvy zpomalí, ale nikdy nezastaví.

Představte si, že děláte systém pro banku. Jednoduše nemůžete klientům říkat - "spadlo to, co se dá dělat, poděkujte téhle IP". Váš pláč mi připomíná Microsoft - no občas to padne, co se dá dělat, nesmíte to a to a to, pak to bude stabilní.

Opravdu spíš zkuste to testování, třeba najdete chybu v jetty nebo jinde a přispějete komunitě. Chápejte, že se lidem špatně obhajuje java na serveru místo třeba php, když tady vidí jak tu pláčete, že to samovolně padá.

[Leoš Literák]

pokud web přestane fungovat při jednom vícethreadovém mirroru, tak je někde něco špatně. A něco je špatně asi v kódu ábíčka, anebo v serverových aplikacích, které servírují obsah. Určitě není chyba v člověku, který mirror provádí. 97 spojení a load 30 NENÍ NIC!!!

Load 30 neni nic? Ja mel za to, ze bezne zatizeni se pohybuje v jednotkach. Bohuzel nemam s cim srovnavat. Tech 97 spojeni jsem myslel z jedne IP adresy. V tuto chvili probihaji dva mirrory, load je 1,5.

To je známý problém javy, také jsme to jednou museli řešit, větší zátěž nám bezpečně shazovala aplikaci. Stačí malé opomenutí a kód přestane být thread-safe, což při běžném provozu funguje a pak to při zátěži "náhodně" padá. Sám bych viděl problém asi tady.

Za thread-safety kodu bych ruku do ohne nedal, ale za ty roky uz je vetsina problemu vychytana. Chyby v teto oblasti se vetsinou projevuji skrze podivne chovani a padani. Nicmene ani pod zatezi abicko nepada a nehazi divne chyby. Jenom bezi hrozne pomalu. To uz by spise vypadalo na prilisnou synchronizaci.

Vaše fascinace minimalizací SQL dotazů je zajímavá, ale tím to zřejmě není. Mirrorovací nástroj má vždy omezený počet threadů a čeká na jejich dokončení, takže při větším počtu SQL dotazů v kódu se odezvy zpomalí, ale nikdy nezastaví.

Abicko se nezastavi. Zvolil jsem v blogu nevhodne slovo "mrtve". Server bezel dale, ale byl velmi pomaly. Stranka se nacital treba i minutu. Nicmene si vazne myslim, ze cast problemu lezi v tom, ze mysql prestava stihat odpovidat. Top ukazuje spousty procesu mysql zeroucich vetsinu procesu. Asi by to chtelo se mrknout na nastaveni mysql, zda je opravdu optimalni. To ale neni muj obor

Dalsi mozny zdroj muze byt jetty. Loni jsem videl nejakou analyzu vykonu servlet containeru a jetty v nem celkem propadlo. Asi bych mel zkusit tu nejnovejsi verzi, ma mit dost optimalizaci. Totez se da rici o JDK 1.5, zatim bezime na JDK 1.4.2.

Tech moznosti je spousta, zatim ale hledam chyby ve svem kodu.

Chápejte, že se lidem špatně obhajuje java na serveru místo třeba php, když tady vidí jak tu pláčete, že to samovolně padá.

Nepada.

[hajma]

Nechci být příliš ofenzívní a chápu že tohle je volnočasový projekt atd bla bla bla, ale pokud web přestane fungovat při jednom vícethreadovém mirroru, tak je někde něco špatně.

Přesně tak, pokud jeden blbej mirroring způsobí DOS na web, tak je někde něco špatně. Přece není normální, aby někdo musel sedět 24/7 u serveru a sledovat logy, jestli si náhodou někdo nepustil httrack...

[Věroš]

Zkuste si naprogramovat složitější aplikaci na webu, pokud ji chcete objektovou (aby se to dobře programovalo a dalo se v tom kódu vyznat) a zároveň ne-úplně jednoduchou, tak se bude stránka generovat dlouho. Domnívám se, že pokud pro každý objekt taháte data z SQL, tak to prostě bude chvilku trvat.

Netvrdím, že se něco nedá zlepšit, možná je chyba v Jetty, možná i v kódu ale vzhledem k tomu, že ABC Linuxu je více méně one-man-show, tak Leoše spíš obdivuju.

Myslím, že load 30 je problém, 97 spojení najednou na slušném HW (nevím, na čem to Leošovi běží) pro statické stránky problém určitě není

PS: Jdu si zkusit omirrorovat vlastní web na testovacím notebooku, schválně jestli se mi povede shodit...

[Leoš Literák]

Jednoprocak P4 1,6 GHz (asi), 512 MB RAM.

Ted jsem analyzoval, co ten clovek tahal. Nejdrive stahnul 4x robots.txt a nasledne jej totalne ignoroval.

Problem testovani je v tom, ze kdyz si to zkusim lokalne, tak mi to krasne bezi a za par minut to vsechno stahne (pouzivam ale linearni wget -i). Na zivem serveru to ale nestiha. Bud to brzdi jetty nebo synchronizace v transparentni cachi.

Kazdopadne ted o vikendu zkusim abicko rozjet pod jetty 5.1.3 a JDK 1.5. To samo o sobe by melo zajistit vyssi vykon nez jetty 4.1 a JDK 1.4.2. Mozna bych mohl zkusit i JVM od BEA, jRockit je optimalizovany pro serverove aplikace.

Nicmene nejdulezitejsi jsou stejnak optimalizace v kodu. Databaze vzdy bude uzkym hrdlem kazde webove aplikace a pokud ji ulehcim, rozhodne to nebude na skodu.

[Věroš]

Tak jsem si zkusil na svém notebooku (Pentium M 1.6MHz, 256MB) 30 paralelních přístupů (pavuk) na menší webový systém (články, diskuse, seriály, rubriky - nová verze pro www.cestovatel.cz ) a uneslo to v pohodě, load se nevyšplhal přes 2.5.

Nepoužívám ale Javu, ale Python + WebwareForPython + CheetahTemplate. Jako DB mám PostgreSQL. Naopak mne mile překvapil výkon Webware.

BTW: V robots.txt se člověk občas dozví zajímavé věci, třeba na www.root.cz mají zakázané cachovat (pravděpodobně) nějaké funkce pro administrátory serveru.

[Věroš]

při 90 paralelních přístupech mi spadl pavuk

Což ovšem nic nemění na tom, že v nějakém RFC je psáno, že na jeden server se navazují maximálně 2-3 spojení najednou.