Dotaz: Re: Vývojáři varují před upgradem na PHP 5.3.7

[Filip Jirsák]

Diskuse vznikla z vlákna této diskuse.

Odpovědi

[Šangala]

No u procesorů jsem napsal „možná“, protože záleží na to co se zpracovává a jak jsou PHP scripty napsané. Např. jednoduché věcí ve velkém počtu - mohli bychom o tom zbytečně diskutovat. Ale ty násobky to je přání, ne realita .
Ale paměť, sorry, ale na tom na čem šlo provozovat několik drobných webů v PHP jsem Javu pomalu ani nerozjel.
I v dnešní době lze velmi slušně provozovat web v PHP s limitem 8MiB na požadavek a prakticky požadavek bere méně - to v Javě pomalu „Hello World“ s nějakým postem v UTF-8 nedáte, nedej bůh zpracovávat nějaké obrázky.

Vlastně mě PHP štve (z některých obecně známých problémů), nicméně pokud se člověk trošku přemýšlí, tak updaty nic nerozbíjí, naposledy se mi to stalo u přechodu s 4 na 5 a to díky blbosti a register globals.

Ale třeba problém konverze čísla 2.2250738585072012e-308 opravil v Javě myslím až Oracle, ale v PHP byla opravena relativně rychle po nahlášení. A opravdu patřičnou hlavičkou bylo možné několik let pár požadavky shazovat Java servery - sám jsem si to zkusil .

[Filip Jirsák]

I v dnešní době lze velmi slušně provozovat web v PHP s limitem 8MiB na požadavek a prakticky požadavek bere méně - to v Javě pomalu „Hello World“ s nějakým postem v UTF-8 nedáte, nedej bůh zpracovávat nějaké obrázky.

Mluvte radši jen za sebe – že něco neumíte, to ještě neznamená, že to nejde.

[Šangala]

Uvažoval jsem doplnit tag <přeháním>…
Ale jinak, ano to platí obecně.

[Filip Jirsák]

Obecně platí leda tak to, že špatný program lze napsat v libovolném jazyce. Jinak běhové prostředí bude mít na výkonu aplikace podíl tak 1 %, a zbývajících 99 % bude ovlivňovat architektura aplikace a konfigurace běhového prostředí.

[Šangala]

Myšleno bylo, že obecně platí: „že něco neumíte, to ještě neznamená, že to nejde“.
Jinak z těmi procenty to nemyslíte váženě, že? :).
Příklad: pokud si vezmete výpočtově náročnou aplikaci s velkým množstvím dat (aby se odchylky hezky projevily), a napíšete ty nejlepší kódy v několika jazycích tak rozdíly budou docela velké a nároky na zdroje , přijde na to. U Javy a Céčka budou pravděpodobně patrné vždy, ale pokud nám do toho spadnou (jednoduchý příklad) unsigned typy ve zdroji dat, tak to bude krásně vidět.
Každý jazyk a prostředí má pro danou úlohu své pro a proti. A udělat z toho 1:99 bych si tedy netroufl…

[Filip Jirsák]

Ta procenta jsou jen nástřel, ten rozdíl bude obvykle ještě větší. Webové aplikace nejsou zrovna dobrým příkladem výpočtově náročných operací, ostatně těch výpočtově náročných aplikací je dnes velmi málo, asi jen v nějakém výzkumu. Ani ty hry nebo zpracování videa už nejsou, co to bývalo. A ani u těch výpočtově náročných aplikací se nedá takhle obecně říci, jaké budou rozdíly – ano, může to být kód, který JVM nesedne a C bude výrazně rychlejší, nebo naopak můžou zvítězit JIT optimalizace a JVM bude rychlejší než nativní kód v C.

[Šangala]

nějakém výzkumu a strojírenství a stavařině a vůbec celém průmyslu .

…nebo naopak můžou zvítězit JIT optimalizace a JVM bude rychlejší než nativní kód v C - jo o tom se píše i ve dvou knížkách co mám kdesi doma, problém je, že jsem se s tím prakticky ještě nesetkal. V praxi zatím jen s tím (nejedná se o webové aplikace), že přechod na Javu znamenal vždy radikální propad výkonu (přechod byl pravděpodobně motivován multiplatformním řešením). V jednom případu návrat ke kompilovanému kódu (myšleno C, C++ či Fortran), v druhém, výpočty vyňaty do kompilovaného kódu a v třetím případě 3D grafika šla do háje co se použitelnosti týče a až v poslední době se dostali do nějakého použitelného stavu (a to už je spoustu let) a na všech setkáních jsou pamětníky bombardováni za degradaci výpočetního výkonu a zbytečné navýšení spotřeby paměti - novým uživatelům to samozřejmě nepřijde, ale pak jsou překvapeni když vidí rychlost a nižší náročnost konkurenčních kompilovaných produktů.
Můj názor: Java má své výhody a velmi cenné, ale výkon a šetření pamětí je jen přání, ne realita

[Filip Jirsák]

Všechny ty aplikace byly napsané stejně dobře a dělaly to samé? Nebo porovnáváte DOSové účetnictví s komplexním ERP systémem?

Myslím, že nikdo netvrdil, že by Java šetřila paměť. Jenom jí plýtvá úplně stejně, jako srovnatelná aplikace napsaná v C++.

[Šangala]

No samozřejmě se snažily dělat to samé, nepopisoval bych něco co nešlo v jedné vývojové linii.
Jak mám vědět, jak byli kvalitně napsané. Nepopisoval jsem žádné měřitelné příklady za stejných definovaných podmínek, popsal jsem mou zkušenost z praxe. A dokud nebudu mít opačné zkušenosti, tak mi nemůže mít za zlé, že si podle toho dělám názor (samozřejmě je i nepatrně podložený mými vlastními zkušenosti s programováním, ale snažím se to vytěsnit, protože ano, Javu neznám dostatečně abych si byl jistý, že je kód správně/efektivně napsaný)
Vím, že se s tím často opakuji, protože se s tím setkávám, ale uznejte, že absence unsigned typů může za určitých okolností až téměř zdvojnásobit požadavky na paměť.

[Filip Jirsák]

Opačné zkušenosti samozřejmě máte, jenomže si neuvědomujete, že v daných případech tam někde také běží Java.Je otázka, zda ty vaše špatné zkušenosti jsou zkušenosti, nebo přání otcem myšlenky. Bezznaménkové typy v Javě nechybí, naopak tam přebývají znaménkové a ostatní primitivní typy.

[Šangala]

První větě nerozumím.
Zpochybňovat moje zkušenosti ze software, který ani neznáte ani neznáte danou problematiku, je nedůstojné. Pro vaši informaci software nakupujeme (pronajímáme licenci) a prvotně nikoho nezajímá jak je to dělané nebo jakou technologii software používá, zajímá nás, jaké jsou požadavky, jak je efektivní a tím pádem jak rychle kolik peněz na něm vyděláme. A pokud nám nová verze na lepším hardware vydělá polovinu, než předchozí verze i když má barevnější ikonky, tak máme problém zjišťujeme kde je problém.
Bezznaménkové typy v Javě nechybí, naopak tam přebývají znaménkové a ostatní primitivní typy. - tak to je objektový fanatismus a pak opravdu jste s pamětí v háji, protože pokud nemáte možnost primitivní typy ukládat v nativní podobě a nejlépe jako raw data, tak máte právě ten paměťový problém.

[Filip Jirsák]

Nedůstojné je něco dokládat „zkušeností“, ze které ze všech stran čouhá to, že jste si nejprve našel oběť, a pak jste teprve hledal důvody, co na ni svedete. Svádět to, že kvůli nějakému programu vyděláváte málo peněz, na programovací jazyk nebo platformu (nevím, co z toho vám vlastně vadí), je dost zvláštní.

Nemožnost ukládat primitivní typy v nativní podobě je váš vynález. Já jsem psal o jazyce, ne o tom, jak to kompilátor přeloží. Navíc máte hodně zvláštní představu o tom, jak programy fungují – pár nějakých čísel opravdu není to, co by v dnes běžně v aplikacích zabíralo zajímavé místo v paměti.

[Šangala]

K první odstavci nemám co dodat.
K druhému odstavci, k vynálezu také nic. Jsou to vaše závěry a nemá smysl je Vám brát.
Ale k poslední větě: pokud já mám zvláštní představu o tom co pojídá paměť, tak Vy prostě žijete v jiném světě než já a odmítáte si jen připustit, že existují i jiné systémy než ty Vaše a vězte je jich spousta. V mém světě všude kolem se ukládá do paměti velká spousta celých nebo reálných čísel a ty zabírají jednotky až desítky GiB (a brzy to budou stovky, zatím nebyl běžně dostupný hardware za rozumnou cenu - a už to vypadá, že je).

[Filip Jirsák]

Co je to za čísla je samozřejmě tajné. Takže nám nezbývá, než věřit vaší interpretaci, že jsou to čísla odpovídající primitivním datovým typům a žádná jiná interpretace není správné nebo dokonce možná. Já s dovolením té vaší interpretaci nevěřím, protože k té interpretaci je potřeba znát něco, co je – soudě dle vašich předchozích komentářů – mimo váš obor.

[Šangala]

Kdyby jsem chtěl s někým dohadovat Je toho více, ale je to například mrak bodů
Polygonová síťě například jako stl
Dráhy pro 3D tisk, případně data pod CNC/NC či jejich simulaci, další mesh-e či prvky atd.
Pravděpodobně i matice vyšších řádů u metod konečných prvků se takto ukládají, ale to nemohu s jistotou říct, protože to nemám prakticky ověřené.
Abych předešel argumentaci, že například jeden vrchol je objekt (nebo dokonce objekt obsahující další objekty), tak může být, ale v paměti se obvykle udržují v blocích jako jednorozměrná či vícerozměrná pole minimálních základních typů, případně pro vizualizaci i normalizovaných do jiných typů zabírajících menší prostor, protože je třeba být co nejefektivnější a každý ukazatel nebo zbytečný bajt navíc je při těch objemech zásadní problém. A také kvalita výpočtu se často odvíjí, od velikost dostupné paměti.
Na poslední až impertinence mohu jen říct, že já zas soudím podle vašich komentářů, že chcete jen všechno negovat a prosadit svou jedinou pravdu, bez jakékoliv sebereflexe.

[Filip Jirsák]

To je celé hezké, ale není tam ani čárka o tom, proč by programovací jazyk musel podporovat číslo jako primitivní typ – udělá se to snadno i bez něj, ba dokonce ten program bude lépe navržen a bude možné jej lépe optimalizovat. A bude to úplně stejně platit pro C++ i pro Javu.

Já svou jedinou pravdu prosadit nemusím. Ale argument „Java je pomalá a paměťově náročná, protože je to Java“ u mne nemá žádnou váhu. Jinak od člověka, který nedokáže rozlišit programovací jazyk a běhové prostředí, bych čekal argumenty odkazující na konkrétní aplikace a nejlépe měření, ne neustálé pokusy o technickou argumentaci o využití paměti apod., o kterém nic nevíte. To, že to nevíte, není špatně a není to kritika, každý umí něco jiného – ale nepokoušejte se to pak používat jako argumenty.

[Mrkva]

To je celé hezké, ale není tam ani čárka o tom, proč by programovací jazyk musel podporovat číslo jako primitivní typ – udělá se to snadno i bez něj,

Asi mi chybí fantazie, ale jak?

[Filip Jirsák]

Nízkoúrovňově pomocí množiny bajtů, nebo klidně objektově (tj. číslo bude objekt). Připomínám, že píšu o programovacím jazyku – objekt Integer pak klidně může kompilátor překládat jako primitivní typ int do bajtkódu Javy (byl by to stejný princip, který se dnes používá pro String). Ostatně díky auto(un)boxingu by už dneska asi šlo ve spoustě případů prostě nahradit int za Integer (atd.) a program by se přeložil a fungoval stejně, jako před změnou (až na tu chybějící optimalizaci).

[Foo Bar]

Nechcete si tu diskuzi vzít někam na svůj blog místo zaplevelování diskuze u článku o bezpečnostní chybě v PHP flejmem o Javě?

[Šangala]

Totot nejsou moje slova „Java je pomalá a paměťově náročná, protože je to Java“,
moje by mohly znít „dle mých praktických zkušeností je Java výrazně více paměťově náročnější a pomalejší než »kompilovaný« kód“ a dodám praktické zkušenosti nejsou založeny na mých experimentech, protože Javu neovládám na tolik, abych si mohli být jistý, že jsem kódu dal tolik jako v C/C++ či jiném jazyku, ale zkušenost je založena na měření řešení obvykle třetích stran, které nám zde prošly.

Tady máte čísla:
Stará čísla ze závěru zprávy hodnocení poslední dříve zmiňované aplikace při přechodu na Javu, po ohlášené výkonové optimalizaci:
…v průměru se paměťová náročnost zvýšila o 10 až cca.300 %
Pozn: nebylo možné přesně stanovit horní hranici, díky velkému rozptylu hodnot u nové verze.
…časy výpočtů o 5-67 % delší…
pomohlo Vám to?, asi těžko…, říká to něco konkrétního o výkonu Javy jako takové, samostatně asi těžko…, máme takových údajů více…, ano, máme tím pádem negativní zkušenost…, ano máme

PS: A popravdě už je mi jedno, co si myslíte o tom co umím nebo neumím rozlišit v jakém levelu, či co vím o práci s pamětí, jak znám který programovací jazyk nebo kam se nám zatoulal 32.bit…
Unavuje mě filozofovat nad abstraktními pojmy, reagovat na další a další argumety či pseudoargumenty, takže klidně spouštím šle - mě už to unavuje jiným to neprospěje
howg

[R]

Napriek tomu, ze vsetci obhajcovia Javy tvrdia, aka je rychla a usporna, tak som este nevidel _ziadnu_ aplikaciu v Jave, ktora by nebola brutalne pomala. Takze bud su vsetky aplikacie napisane zle alebo co?

[Heron]

Můžu mluvit pouze sám za sebe.

Zatímco v C jsem psal program, který dělal jen jeden výpočet (například), protože to samo o sobě byla výzva; tak napsat v Javě totéž správně svádí ke komplexní datové struktuře, která se pak velmi snadno rozvíjí. A nakonec se na to nabalí logování, různé měřící body, správa selhání apod.

Takže, zatímco program v C dělal jednu věc, tak program v Javě dělá také jednu věc, ale kolem toho jich nabízí ještě dalších 100. Ono je to totiž hrozně snadné a zábavné to psát.

Neznám malý program v Javě. Znám pouze velké programy v Javě. Torrent klient může být buď ctorrent, nebo Azuerus s grafy, pluginy, vlastním vyhledávačem apod. To první je v C, to druhé v Javě. Takhle to dopadá se vším. OpenFire není jen jabber server, ale poměrně komplexní "moloch". Minecraft začínal jako studentský infinite rendered, dnes je to rychle se rozvíjející složitá hra. Abclinuxu také není malé. RSSOwl začínalo jako obyčejná rss čtečka, dnes je to "moloch" na platformě Eclipse. Atd.

Ty programy jsou rychlé. Jsou rychlé, pokud trvale běží v Server Hot Spot JVM. Pokud to někdo spouští při každé akci (tak jako C binárky), tak se mu to samozřejmě bude zdát pomalé.

[Filip Jirsák]

Abíčko je brutálně pomalé?

[Sten]

Ano, přinejmenším při vkládání příspěvků je to dost znatelné. Anebo ve srovnání s CppCMS.

[Heron]

Příklad: pokud si vezmete výpočtově náročnou aplikaci s velkým množstvím dat (aby se odchylky hezky projevily), a napíšete ty nejlepší kódy v několika jazycích tak rozdíly budou docela velké a nároky na zdroje , přijde na to.

Zde platí, že nejlepší statistika je ta, kterou si zfalšuji sám. Java nejdřív měla knihovnu Math napsanou v C, v nějaké verzi (něco jako 1.2), to bylo kompletně přepsané do Javy. Výsledná knihovna byla stejně rychlá jako původní verze.

Viděl jsem výsledky výpočetních benchmarků, kde byla java nejrychlejší. I to jde a poměrně snadno. Stačí, když se vybere takový JIT a takový kompilátor C takový, aby ten JIT produkoval rychlejší kód.

Jinak to, že Java je náročná na paměť neberu už ani jako vtip. To je totéž, jako říkat, že ifconfig funguje na jádře 3.1 . Pokud chci, tak javovský program klidně může volat každou ms garbage collector. Pokud systému dochází paměť, tak to JVM tak dělá. Ale proč bych to měl vůbec chtít, když má systém paměti na rozdávání? Já naopak chci, aby všechno co může používalo paměť jako cache. Takže ano, opticky vypadá javovský proces jako paměťově náročný. Ale jen pro ty, kteří nevědí, co je uvnitř.

[Šangala]

Jo-jo benchmarků…
Garbage collector každou ms, nebude tam troška režie?
Ať si cache-uje, ale pak ať nevytěžuje všechny jádra a nezadrhává při přesýpání, když potřebuji načíst milardu int-ů a ať se mi to vleze do 8GiB RAM (pominu-li, že chci unsigned int-y). A taky bych někdy rád aby na mi tu paměť nechal i na jiné věci

[Luboš Doležel (Doli)]

Ano, na drobné weby typu "Personal Home Page" je PHP ideální. A tím to končí.

[pools]

http://root.cz

[Luboš Doležel (Doli)]

Ne, že by to něco jednoznačně ukazovalo, pustil jsem na to hromadu požadavků pomocí ApacheBench a odezva je velmi znatelně horší než u AbcLinuxu/ITBizu. Navíc je otázka, na kolika serverech jim to běží. Naše weby v podstatě na jednom stroji.

Root.cz (PHP a kdoví co):

  50%    866
  66%   1577
  75%   2561
  80%   3293
  90%   5068
  95%   6076
  98%   7979
  99%   9149
 100%  10968 (longest request)

AbcLinuxu.cz (Java + JDBC - MySQL):

  50%    389
  66%    408
  75%    428
  80%    441
  90%    534
  95%    695
  98%    916
  99%   1129
 100%   4174 (longest request)

ITBiz.cz (Java + Hibernate - MySQL):

  50%    253
  66%    268
  75%    280
  80%    292
  90%    343
  95%    463
  98%   1096
  99%   1440
 100%   3274 (longest request)

AutoLevel.cz (taky moje dílo) (Java + JDBC - MySQL)

  50%    185
  66%    188
  75%    191
  80%    195
  90%    209
  95%    273
  98%    326
  99%    823
 100%    905 (longest request)

Neboli weby můžete dělat klidně v Bashi, otázkou pak je, jak to pojede.

[Mrkva]

To je trochu nefér srovnání. Nemáš žádná data o HW serverů, aktuální zátěži a podobně. Z toho fakt nemá cenu vyvozovat jakékoliv závěry.

[Filip Jirsák]

Řekl bych, že do této diskuse to nefér srovnání dokonale zapadá.

[chrono]

Na abclinuxu.cz veľmi dlhý čas trvalo vkladanie príspevku pol minútu alebo aj viac (v poslednom čase je to našťastie lepšie).

[Luboš Doležel (Doli)]

Jojo, to tak bývalo. Zápisové operace zůstávaly neskutečně dlouho zablokované. Ani nevím proč, protože u mně (myšleno na mnou provozované databázi) se to nikdy nedělo.

[Šangala]

Co teď napíšu nemyslím jako nějaký útok, ale jen pro srovnání, že pocity mohou být různé.
U abíčka mám často (i několikrát za den) docela dlouhou odezvu (několika sekundovou) a to z minimálně ze dvou různých připojení a sem tam to vyšumí v timeoutu a 1-2× za měsíc mě pobaví krásná několika-stránková vyjímka či to nejzvláštnější už jsem několikrát (2-3×) viděl i nějaký, podle mě, Java kód.
No a na root-u se mi nic z toho nestává/nestalo, ale chodím tam zas výrazně méně.
Výhody Javy vidím někde jinde, rozhodně ne, v šetření zdroji - zvláště pamětí.

Nicméně svůj první post jsem poslal jako popíchnutí položertem, takže ani nechci to někam dál tlačit. Takže uznávám, že Java je jednoznačně lepší řešení než PHP v oblasti správy kódu, a že může být to řešení i za určitých okolností rychlejší než v PHP (ale to s tou pamětí, při velkém zatížení serveru a množstvím dotazů nedám ).

[pools]

Root:

  50%    191
  66%    224
  75%    265
  80%    280
  90%    299
  95%    334
  98%    841
  99%   3357
 100%   3363 (longest request)

Abclinuxu:

  50%    203
  66%    261
  75%    282
  80%    288
  90%    373
  95%    630
  98%   3238
  99%   3356
 100%   4278 (longest request)

[jos]

aneb nevěřím statistikám které si sám nevycucám z prstu

[pools]

tak tak zkus to taky, ab najdeš v apache2-utils nebo tak nějak:
ab -n 300 -c 3 http://abclinuxu.cz/
<< s tímhle sem to "vycucával z prstu" já

[Luboš Doležel (Doli)]

To by mě zajímalo, jak jsi k tomuhle dospěl, protože pokud zadáš jen http://abclinuxu.cz/, tak ti to neobslouží Jetty, ale jen Apache frontend, který ti okamžitě vrátí redirect. A to stihne za 50ms. Tvoje čísla nemohou odpovídat tomu příkazu.

Mimochodem www.abclinuxu.cz vs. www.root.cz podle tvých parametrů dává ábíčku poloviční až třetinové časy.

[Šangala]

Zase já , jsem to zkoušel (ještě před tím) a právě mi to nehrálo, nicméně toto jsou ty nejlepší co jsem naměřil:

  50%    320
  66%    324
  75%    326
  80%    327
  90%    343
  95%    362
  98%    384
  99%    396
 100%    396 (longest request)

Ale taky:

  50%   1784
  66%   1843
  75%   1902
  80%   1994
  90%   2297
  95%   2530
  98%   2947
  99%   2965
 100%   2965 (longest request)

a u root-u, jsem naměřil nejhorší (nejlepší se Abíčku nevyrovnaly)

  
  50%    880
  66%   1256
  75%   1403
  80%   1481
  90%   1988
  95%   2436
  98%   2602
  99%   3206
 100%   3206 (longest request)

A né, že bych z toho dělal nějaké závěry… a doufám, že jsme společně něco na chvilku odstavili

[pools]

Dívej, prostě jsem z legrace dal do googlu "ubuntu apachebench" a v jednom z prvních nálezů byl příkaz který jsem aplikoval těsně za sebou jak na root, tak na abclinuxu. Vůbec nevím co ty čísla znamenají, jediné co vím je, že jsem je nijak neupravoval...

[pools]

První pokus:

  50%    767
  66%    785
  75%    793
  80%    817
  90%   1018
  95%   1304
  98%   1711
  99%   3690
 100%   3846 (longest request)

Druhý pokus:

  50%    730
  66%    742
  75%    752
  80%    762
  90%    781
  95%    864
  98%   1336
  99%   1699
 100%   1728 (longest request)

Třetí pokus:

  50%    751
  66%    764
  75%    775
  80%    782
  90%    874
  95%   1300
  98%   1471
  99%   2059
 100%   2188 (longest request)

<< pro http://www.abclinuxu.cz/

[Jendа]

DoSovat konkurenci, no fuj .

[Michal Kubeček]

Taky si říkám, že by mne nenapadlo pouštět ab na cizí server (bez předchozího souhlasu).

[Jendа]

No vidíš, teď Root vrací HTTP/503.

[cezz]

PHP ale naozaj zacalo ako "Personal Home Page Tools" a to ze to par odvazlivcov pouziva na nieco vacsie este nic neznamena