Výkon webové aplikácie - Java vs hocičo

[Palo]

Zdravím.

Na serveri sa budú upravovať "dávkovo" dáta (rozumej neinteraktívne). Existuje nejaká výkonovo zmysluplná alternatíva k Jave/JIT, ktorá by ušetrila zmysluplno výkon? povedzme o 10 - 15%?
Napadol mi nejaký framework pre C/C++ (http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#C)
Samozrejme ide o schopnosti programátora a optimalizáciu. Aby bol server čo najlepšie využitý.

Ďakujem za rady.

[Reklama]

[h7]

Zdravím, předně bych se zamýšlel na tím, zda se to vůbec vyplatí. Většinou bývá v celé aplikaci jen velmi malá část kódu, kterou je třeba/vhodné výkonnostně optimalizovat, protože zabírá velkou část zdrojů jako CPU, RAM apod. Takže psát to celé v C typicky nedává smysl - sice ušetříte nějaké ty systémové zdroje, ale produktivita práce půjde silně dolů. Nicméně napsat si pár kritických funkcí v C může být dobrý nápad. Samozřejmě ale záleží na konkrétním projektu, který znáte nejlépe vy. Bez nějakých konkrétnějších informací těžko něco radit.

Ad C/C++ framework: Framework k čemu? Webový framework je typicky právě na tu interaktivitu, tedy tvorbu webové aplikace s GUI nebo nějaké "interaktivní" webové služby, než na nějaké dávkové zpracování. Dávková úprava dat je tak obecný pojem, že si lze pod tím představit kde co. Takže opět těžko něco konkrétního radit.

[fdvgdsfsda]

my pouzivame mod_wsgi a python. frameworku nad wsgi je pak X.

[Jan Forman]

Zdravím.

Na serveri sa budú upravovať "dávkovo" dáta (rozumej neinteraktívne). Existuje nejaká výkonovo zmysluplná alternatíva k Jave/JIT, ktorá by ušetrila zmysluplno výkon? povedzme o 10 - 15%?
Napadol mi nejaký framework pre C/C++ (http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#C)
Samozrejme ide o schopnosti programátora a optimalizáciu. Aby bol server čo najlepšie využitý.

Ďakujem za rady.

Moc se to nevyplatí, železo obvykle bývá mnohem levnější než programátor.
Tudíž sice se píšou optimalizované věci, ale až od většího množství serverů (řádově desítky stovky tisíce - tam to má smysl).
Jinak v C zcela jistě jen drobné části (vývoj je opravdu dost náročný a háklivý na chyby).

Teď je otázka to co vlastně má být? Je to služba (soa/rest), nebo frontend?

[Palo]

Vďaka za odpovede.
Išlo by o obrázky (rotácie, zmenšovanie, prevody farieb a pod.) Klient klikne na "OK" a server sa rozbehne na 100% výkonu a čaká sa.
Napadlo mi urobiť frontend v HTML5 a na serveru na uložených dátach by sa to spracovávalo. Že HTML5 frontend by generoval príkazy pre server.

... chcem na jeden server od Amazonu narvať čo najviac používateľov. Takže preto riešim otázku výkonu. Zatial chcem (správne) vybrať technológiu, ktorú v prípade úspechu nieje problém vyladiť, ale napr. Python (môj pôvodný favorit) ja na to určite výkonovo určite horšie ako Java. A Java je vraj horšia ako C. Napr tu Java nevychádza v niektorých testoch tak zle http://www.root.cz/clanky/pohled-pod-kapotu-jvm-vykonnost-aplikaci-vytvorenych-s-vyuzitim-sdljava-v-porovnani-s-nativnimi-aplikacemi/

Videl som prezentáciu z Linkedin, že používajú Javu a v nej bol na začiatku vtip o Ruby on Rails, takže usudzujem, že Java je asi lepšia na tento projekt ako RoR alebo zacitujem z článku "Škálovat lze téměř cokoliv, když Facebook jede na PHP, a Google bylo postavené na Pythonu, tak už je možné asi všechno."

Článok http://www.itefektivne.cz/archives/2050

Zatial vedie Java kvôli zázemiu, aj keď by som radšej chcel Python.

Otázka znie: Akú technológiu dneška by ste poradili Zukenbergovi na nakódenie Facebooku (napr).

[Reklama]

[Palo]

A ešte som obzeral napr. toto http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#C

[zboj]

Vďaka za odpovede.
Išlo by o obrázky (rotácie, zmenšovanie, prevody farieb a pod.) Klient klikne na "OK" a server sa rozbehne na 100% výkonu a čaká sa.
Napadlo mi urobiť frontend v HTML5 a na serveru na uložených dátach by sa to spracovávalo. Že HTML5 frontend by generoval príkazy pre server.

... chcem na jeden server od Amazonu narvať čo najviac používateľov. Takže preto riešim otázku výkonu. Zatial chcem (správne) vybrať technológiu, ktorú v prípade úspechu nieje problém vyladiť, ale napr. Python (môj pôvodný favorit) ja na to určite výkonovo určite horšie ako Java. A Java je vraj horšia ako C. Napr tu Java nevychádza v niektorých testoch tak zle http://www.root.cz/clanky/pohled-pod-kapotu-jvm-vykonnost-aplikaci-vytvorenych-s-vyuzitim-sdljava-v-porovnani-s-nativnimi-aplikacemi/

Videl som prezentáciu z Linkedin, že používajú Javu a v nej bol na začiatku vtip o Ruby on Rails, takže usudzujem, že Java je asi lepšia na tento projekt ako RoR alebo zacitujem z článku "Škálovat lze téměř cokoliv, když Facebook jede na PHP, a Google bylo postavené na Pythonu, tak už je možné asi všechno."

Článok http://www.itefektivne.cz/archives/2050

Zatial vedie Java kvôli zázemiu, aj keď by som radšej chcel Python.

Otázka znie: Akú technológiu dneška by ste poradili Zukenbergovi na nakódenie Facebooku (napr).

To chce nějakou dobrou knihovnu na obrázky (která umí využívat GPU apod.) a tu volat přes JNA. Taky to bude chtít neco jako libdispatch.

[to_je_jedno]

Vyborne, konecne zadani. Takze je uplne jedno jestli to napises v php, jave nebo assembleru. Podstatne je jenom to co budes volat na ty transformace. Je pravda, ze me vykon nikdy moc netrapil takze jsem nic jineho nez imagemagick nikdy nehledal a nezkousel.

[k77]

Zdravím.

Na serveri sa budú upravovať "dávkovo" dáta (rozumej neinteraktívne). Existuje nejaká výkonovo zmysluplná alternatíva k Jave/JIT, ktorá by ušetrila zmysluplno výkon? povedzme o 10 - 15%?
Napadol mi nejaký framework pre C/C++ (http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#C)
Samozrejme ide o schopnosti programátora a optimalizáciu. Aby bol server čo najlepšie využitý.

Ďakujem za rady.

tu je porovnanie webovych frameworkov: http://www.techempower.com/benchmarks/

[perceptron]

si tiez myslim, ze sa to deli na dve veci: jednak upload tych obrazkov cez http a prezentacia vysledkov a jednak tie transformacie

imho to webove rozhranie mozete urobit v hocicom, predpokladam, ze pojde o klasicky crud a hadat sa o percentka vykonu v takych aplikaciach je strata casu a predcasna optimalizacia

btw, s facebookom by som sa neporovnaval, to je svet miliard uzivatelov, kde su vsetky rady kratke (vid ich php a nimi vyvinuty virtualny stroj pre php)

[Kit]

Išlo by o obrázky (rotácie, zmenšovanie, prevody farieb a pod.) Klient klikne na "OK" a server sa rozbehne na 100% výkonu a čaká sa.
Napadlo mi urobiť frontend v HTML5 a na serveru na uložených dátach by sa to spracovávalo. Že HTML5 frontend by generoval príkazy pre server.

HTML5 by mohlo dělat přímo ty výpočty. Tím by se ušetřilo nejvíc výkonu na serveru.

[lobo]

To chce nějakou dobrou knihovnu na obrázky (která umí využívat GPU apod.) a tu volat přes JNA. Taky to bude chtít neco jako libdispatch.

myslim ze na hostovanom virtuale sa nedostanes na GPU a na hostovanom zeleze obvykle GPU byva na urovni Intel shit...
cize to GPU ti podla mna moc nepomoze...

Buzzword warning :-)
ak by bolo potrebne mat seriozny vykon, asi by som postavil pocitac s 2-4 grafickymi kartami s podporou CUDA a pouzil image manipulation libriaries s podporou CUDA
zaujimavy clanok :  Debunking the 100X GPU vs. CPU myth http://www.hwsw.hu/kepek/hirek/2010/06/p451-lee.pdf

[Juraj]

Aj tu bol o tom nedavno clanok - namiesto trapenia sa s HW a optimalizaciou, pouzit na to davkove spracovanie spot instancie v Amazon EC2 alebo podobne, ponukaju aj Nvidia GPU pristup.

[txt]

Vynášet soudy ohledně výkonnosti si netroufám, ale na chroustání dat je Python poměrně silný. Knihovny pro manipulaci s daty (obrazem) jsou napsány např. v C a samotný python spíš slouží jako lepidlo.
Uvažuješ o paralelizaci?

[Palo]

Hm.. knižnice Pythonu sú v C, to mi ušlo. Super.
Napadlo mi urobiť výkonový test s knižnicami v Jave, Pythone a ďalších.
Amazon a jeho lacne ale volatilné počítanie som mal v pláne využívať.
Paralerizácia asi nie, veď predpokladám, že na ďalšom jadre by bežal už iný užívateľ.
Ale pri hľadaní knižníc si prejdem aj podporu GPU/CUDA a ponuku Amazonu.

Vďaka za spätnú väzbu.