Nefunkcni pirateleaks

[Petr.Vileta]

Rozumi tomu nekdo? ^^^

Kdysi jsem si delal takovy test na "serveru" teto konfigurace:
CPU: Intel Celeron 266 MHz
RAM: 512 MB
Webserver: Apache 1.2
MySQL: 3.23.56
PHP: 4.3
Perl: 5.6

Zkusil jsem napsat statickou html stranku s tabulkou o 3 sloupcich a 1000 radkach. Tech 1000 rows bylo samozrejme take v MySQL tabulce. No a pak jsem napsal dalsi stranku v php a jeste totez v Perlu, oboji s pouzitim MySQL.

No a nakonec jsem pozadal jednoho znameho, ktery odnekud z university spustil jakysi zatezovy test webu. Bohuzel se mi vysledky kamsi podely, ale pamatuji si, ze pri statickem html byl load neco kolem 0.2, pri Perl+MySQL neco kolem 0.6 a pri php+MySQL 1.1

Mozna, ze se pomery od te doby zlepsily, ale porad mam ten dojem, ze php je pro rozsahlejsi aplikace proste nevhodny, protoze nejvic zatezuje server. Ono se v nem snadno programuje ale znate to, cim snadneji se s necim pracuje, tim vice s tim pracuje lidi, kteri tomu vubec nerozumi a tim horsi dila vytvori. Najit prasacky napsny program v C je tezke, protoze pomerne malo programatoru pracuje v C. Najit prasacky napsany program v Perlu uz je o neco snazsi, ale prasacky napsanych programu ve Visual Basicu nebo PHP jsou tuny

[Petr Stehlik]

A vy ste snad cekali, ze to vydrzi?

To jsme fakt nečekali, že v sobotu Úřad pro ochranu osobních údajů vydá nějaké stanovisko.

Jestli to chápu dobře, tak virtuální stroj s online konfigurací RAM a CPU pro zvládání špiček přístupů nám nepomůže, pokud předem nedokážeme odhadnout, kdy nás kdo kde nalinkuje (což se právě stalo). Škoda, byl to dobrý plán, ale pirateleaks by musel mít nějaký skoroautomatický systém na monitoring zátěže a rychlou změnu parametrů virtuálního HW (což zřejmě nefunguje dostatečně rychle, jak jsem pochopil z Vítkovy poznámky o nezměněné velikosti RAM).

S kým/kde se probírá technické řešení webu pirateleaks? Všiml jsem si poznámek o httrack - zkoušeli jste z dokuwiki vyexportovat stránky jako statické html? Dokuwiki na to podporu má - dal by se nejspíš automaticky udělat celý web staticky jen z čistého HTML, a teprve ten rozmirrorovávat. To už by snad httrack nedodrbal, a hlavně by lighttpd v klidu stíhal servírovat čisté HTML i pro tisíce požadavků za zlomky sekundy.

EDIT: měl jsem na mysli tohle:
http://www.dokuwiki.org/export
http://www.dokuwiki.org/plugin:siteexport
http://www.dokuwiki.org/plugin:offline
http://www.dokuwiki.org/plugin:dokukiwix

Teď jen vyzkoušet a vybrat ten modul, který fakt funguje...

[Jiri.Kaderavek]

Nevím, kdo si tady dělal zátěžové testy. Já si je pomocí Loicu dělal, jak na náš web, tak na PL. Takže zhruba tuším co ustojí (veliký kulový a náš web 2x veliký kulový). Petr Vileta tady argumentuje zkušenostmi z minulého milénia. Petře, nabízel jsem ti, že můžeš být správcem PL, nějak se ti do toho nechtělo, zato rozumy rozdáváš jak na běžícím pásu. Zkus si pomoci firebugu zanalyzovat, kolik jde při jedné návštěvě webu požadavků na server (css, image, skripty), zkus si zanalyzovat, kolik se dělá na běžném CMSku, které zvládá obsloužit Jakub nebo Jarda includů a prosím nesrovnávej to s jedním cyklem na mysql.

Co se týče optimalizace na statiku, tak byla provedena, ale kvůli neposlušnému chování httracku jsme se domluvili, že to na statický mirror přepneme jen když budeme čekat zátěž (takže nečekaná zátěž = žádná optimalizace). Jinak dalšími možnostmi optimalizace (pro někoho, kdo se o to postará) je nasazení php přes mod_fcgid (rychlejší než mod_php, lepší práce s pamětí) a nasazení APC nebo xcache (tu jsem právě teď na warrioru nasadil a máme o 100% lepší výkon).

Mj., já platím u Masters za pořádnou konfiguraci 5.500,- Kč měsíčně (pronajatý stroj), těžko s tím srovnávat řešení za 160 Kč měsíčně. Chceme moc peněz za málo muziky a nemáme správce (teď už snad ano, ale točí se u toho stále ty stejné osoby - a to je důvod, proč s tím nechci mít nic společného, protože kritiků je vždy, když se něco stane tisíc, ale těch co by pomohli něčím jiným než řečma, ty aby člověk hledal jak jehlu v kupce sena - čest výjimkám, kteří v diskusi argumentují relevantně). Jo a veliké díky Brožovi, bez něj bysme byly v prdeli úlpně.

EDIT: Teď jsem si dělal testy s xcache a jsou velice zajímavé. Na LOICu stihne warrior s xcache v pohodě obsluhovat 100req/s, zatímco bez xcache asi tak 20req/s. Takže xcache dává 100% nárust výkonu a 5-tinásobnou obslužnost. Pro laiky, xcache je tzv. opcode keš, tzn. že kešuje mezivýsledky překladu php (alternativní produkty např. APC keš apod. - více zde http://en.wikipedia.org/wiki/List_of_PHP_accelerators)

[Anonym101]

podle me byla hlavne kravina ze login a pristup k dns ma tak malo lidi (1?, 2?). hrat si na to kdo je spravce je supr ale v pripade problemu by taky mohl byt dostupny ...

[Petr.Vileta]

Petr Vileta tady argumentuje zkušenostmi z minulého milénia. Petře, nabízel jsem ti, že můžeš být správcem PL, nějak se ti do toho nechtělo, zato rozumy rozdáváš jak na běžícím pásu. Zkus si pomoci firebugu zanalyzovat, kolik jde při jedné návštěvě webu požadavků na server (css, image, skripty), zkus si zanalyzovat, kolik se dělá na běžném CMSku, které zvládá obsloužit Jakub nebo Jarda includů a prosím nesrovnávej to s jedním cyklem na mysql.

Jirko, nejde o mou neochotu, ale o me male znalosti v oblasti spravy weboveho serveru. Pokud by slo jen o to, ze mi v noci (kdy jsem prevazne v provozu) prijde mailem nejaky warning, ja sahnu na server a zmenim nejake parametry podle navodu, tak to klidne muzu delat.

A zkusenosti z minuleho tisicileti jsem sem psal prave proto, ze ta masina byla vyslovene slaba a kazdy zbytecny include navic se tam okamzite projevil. Mimochodem tuhle je nejaky benchmark http://blog.famzah.net/2010/07/01/cpp-v ... benchmark/

[Lukas.Novy]

http://blog.famzah.net/2010/07/01/cpp-v ... benchmark/

Jsem šokován! Interpretované jazyky jsou při matematických výpočtech pomalejší než nativní kód! Perl poráží PHP v disciplíně, na kterou se vůbec nehodí!

[jzvc]

Jestli to chápu dobře, tak virtuální stroj s online konfigurací RAM a CPU pro zvládání špiček přístupů nám nepomůže, pokud předem nedokážeme odhadnout, kdy nás kdo kde nalinkuje (což se právě stalo). Škoda, byl to dobrý plán, ale pirateleaks by musel mít nějaký skoroautomatický systém na monitoring zátěže a rychlou změnu parametrů virtuálního HW (což zřejmě nefunguje dostatečně rychle, jak jsem pochopil z Vítkovy poznámky o nezměněné velikosti RAM).

Ciste pro info, kazdej normalni virtualizacni nastroj umi RAM pridelovat dynamicky = podle potreby, ze ste zvolili hosting, kde vam to pridelej natvrdo ... Normalne se to dela tak ze se rekne "chcem 512MB (rekneme), ale v pripade potreby 8GB", ten stroj bude po 99% casu pouzivat trebas i min nez tech 512, ale jevit se mu to bude jako tech 8GB. Moh bych tady natipat obrazky z vmware jak to vypada, kdyz ma HW stroj 2x4 CPU a 128GB RAMky, pricemz pridejeno je nasobne vic, ale vpohode je stale dost volnyho vykonu i RAM (bezi na tom cca 20 virtualnich stroju). Navic umi i v pripade potreby presunout zatizenej virtual na jinej HW v clusteru.

BTW: Pokud me skleroza neklame, tak bez nejakejch automatismu se da vmware provozovat i zdarma (nemyslim v nejakym OS ale primo jako primarni system), a presuny se daj resit ve vlastni rezii. IMO vlastni HW s vmwarem by byl pro CPS lepsi nez tohle bastleni "aby to moc nestalo a moc nefungovalo".

podle me byla hlavne kravina ze login a pristup k dns ma tak malo lidi (1?, 2?). hrat si na to kdo je spravce je supr ale v pripade problemu by taky mohl byt dostupny ...

Proc to bydefault nenamirite na vic stroju ? I bez nejakyho algoritmicky dokonalyho rozdelovani ti 2 A zaznamy rozdelej zatez bywoko napul ...

[Anonym101]

Ciste pro info, kazdej normalni virtualizacni nastroj umi RAM pridelovat dynamicky = podle potreby, ze ste zvolili hosting, kde vam to pridelej natvrdo ...

to jsem taky myslel, jenze kdyz jsem tam natukal zvednuti pameti, tak nic. jen to napsalo ze se ceka zmenu konfigurace (takze se asi poslal mail spravci ze ma pridat pamet a v sobotu nepracoval)

podle me byla hlavne kravina ze login a pristup k dns ma tak malo lidi (1?, 2?). hrat si na to kdo je spravce je supr ale v pripade problemu by taky mohl byt dostupny ...

Proc to bydefault nenamirite na vic stroju ? I bez nejakyho algoritmicky dokonalyho rozdelovani ti 2 A zaznamy rozdelej zatez bywoko napul ...

me to uz napadlo, nasmerovat to treba na par "mirroru" (treba udelanych takhle https://www.ceskapiratskastrana.cz/foru ... 473#p97167 )
ale neni to na me:(

[Petr.Vileta]

http://blog.famzah.net/2010/07/01/cpp-v ... benchmark/

Jsem šokován! Interpretované jazyky jsou při matematických výpočtech pomalejší než nativní kód! Perl poráží PHP v disciplíně, na kterou se vůbec nehodí!

Tady nejde o srovnani s Ceckem, ale o porovnani Perlu a PHP a trvam na tom, ze pokud oba pojednou v nativnim modu, tak PHP silne prohrava a pokud to pojede v mod_php a mod_perl (popr. mod_cgi) tak jeste porad bude Perl o neco rychlejsi.
No tak tuhle mas dalsi, ten uz je mirne relevantnejsi http://www.skitoy.com/p/performance-of- ... d-perl/160
Muzeme se domluvit, ze napisu dva shodne skripty v Perlu a PHP a otestujes to na mem serveru nebo kdekoliv jinde.

[Jiri.Kaderavek]

Muzeme se domluvit, ze napisu dva shodne skripty v Perlu a PHP a otestujes to na mem serveru nebo kdekoliv jinde.

Můžeme se domluvit, že ty svoje krutě off-topic zprávy budeš psát mimo podatelnu TO, možná dokonce i mimo pirátské fórum? Vždyť stačí před stisknutím tlačítka Odeslat porovnat nadpis vlákna s tím, co's vyplodil, a musíš vidět, že srovnávání rychlosti perlu a php je naprosto irelevantní, když se tu bavíme o tom, že Dokuwiki na poddimenzovaném železe nestíhá nečekaný nápor a řešíme to kešováním, statickým HTML a mirrorováním.

To filozofování by bylo nejlepší přesunout někde do chatu, třeba přes pirátský jabber v nějaké vhodné místnosti, kterou by AO ve spolupráci s TO mohl vytvořit - mohla by se jmenovat třeba "Bezva nápady a úvahy".