Facebook és a Java (pontosabban a JVM)

Sokan emlegetik a Facebookot akkor, amikor PHP-s weboldalak teljesítményéről, meg magáról a PHP platformról van szó. Azonban elfelejtik azt, hogy a Facebook kényszerült arra, hogy elkészítse a HipHop-ot, és most úgy néz ki, ezt is egy JVM-mel cserélik ki, a PHP-s kódokat JVM-en fogják futtatni. Kíváncsian várom az eredményét a dolognak. Azt tudni lehet, hogy a twitternek megérte Java alapokra helyezni a keresőjét, 3x-os latency csökkenést értek el tavaly.
Forrás: http://nerds-central.blogspot.hu/2012/08/facebook-moving-to-jvm.html

( pch v | 2012. 08. 14., k – 12:36 )

Azért a g+ még mindig fényévekkel gyors, és nem kényszerültek ilyenekre.
Igaz nincs annyi user, de a facebook nem az userek száma miatt lassú. (imho)

pch
--
http://www.buster.hu "A" számlázó
--

"GMail az server-side javascript"
links or didn't happen.

szerk. okes, megtalaltam.
"At the USENIX annual conference last month, Gmail engineer Adam de Boor surprised the audience by noting that the company's Gmail service was written entirely in JavaScript, and that all of its code, around 443,000 lines worth, was written by hand."
http://www.infoworld.com/d/developer-world/google-executive-frustrated-…

De itt a vezeto fejleszto azt mondja, hogy nem:
http://www.quora.com/What-programming-languages-is-Gmail-implemented-in
http://en.wikipedia.org/wiki/Paul_Buchheit

( GCS v | 2012. 08. 14., k – 13:19 )

Olyan nagy különbség lenne a fordított PHP és JVM class-ok között? Ez meglepő, mivel a fordított PHP kód már gépi kód, JVM meg továbbra is byte kód.

Olvasd el még egyszer: "a fordított PHP" kód, a faszbúk hiphop fordítójával lehet első lépésben C++ kódot generálni. Onnan meg gépi kód és natívan fut a procin.
JVM class meg byte kód, először értelmezni kell azt és JIT-el fordítani. Ez overhead az előbbihez képest.

Most megint az van hogy megszakértjük a HUP-ról a Facebook technológiai döntéseit? Rendben van hogy pár száraz tényt feltárunk (amivel amúgy mindenki tisztában van), de nem tudjuk a döntés mögöttes hátterét, mert nyilván nem véletlenül csinálják.

--
http://neurogadget.com/

Ennyi információból nem derül ki semmi.
A performance kérdés olyan, hogy "don't argue, benchmark". Nem érdemes előre tervezni itt, olyan helyen lehet bottleneck az alkalmazásodban, ahol nem gondolnád. Akár még a végén a filerendszer is lehet a sebesség gátja. A lényeg: nem tudsz az elején jól dönteni. Egy alkalmazásnál csak futásidőben tudod megmondani, mi okozza a lassúságot. Akár egy rossz DB-index is lehet, nem tudni ezt előre, nem ismertek a használat mintázatok.
Viszont egy másik aspektust megnézve, Javaban akkora az ecosystem (akár csak akkor is, ha a nyílt forráskódú komponenseket, libraryket tekintem), hogy buta választás lenne NEM Javaban csinálni.

"A performance kérdés olyan, hogy "don't argue, benchmark". Nem érdemes előre tervezni itt, olyan helyen lehet bottleneck az alkalmazásodban, ahol nem gondolnád."

Azért ez elég sarkos kijelentés. Szerintem igenis lehet előre tervezni a már rendelkezésre álló információk alapján, pl. említed a fájlrendszert, aminek az áteresztő képességét már akkor meg lehet mérni, amikor az alkalmazásból még egy sor nem készült el.

Az FS teljesítményét is befolyásolja a használati minta: sok kis file-t fognak feltölteni, keveset, de nagyot, mennyi lesz az írás/olvasás aránya, fontos-e a hozzáférési időket is nyilvántartani, vagy csak a módosítási időket stb. Esetleg az is számít, hogy az egyes mért mennyiségeknek mekkora a szórása. Van ahol az a fontos, hogy a szórás kicsi legyen, de az nem számít igazán, mekkora a várható érték, van ahol az mindegy, csak éppen a legmagasabb mért mennyiség legyen egy bizonyos szint alatt.

Sok mindent megmérhetsz, de egyértelmű eredményt egyik mérés sem fog adni. Van ami ebben erős, van ami abban, a használati minták üzem közben majd megmutatják, mire van szükség.

Viszont ismered a rendszer felé támasztott igényeket, ebből tudod, hogy milyen paramétereket érdemes figyelembe venni. Elvégzed a megfelelő méréseket, ebből el tudod dönteni, hogy melyik használati minta lehet hatékonyabb. Nyilván nem mehetsz biztosra, de inkább mérések befolyásolják a döntéseket, mint a dobókocka.

Azert nem teljesen zoldmezos a dolog, vannak patternek, amiket ki lehet zarni, peldaul egy ilyennek nem olyan a terhelese, mint mondjuk egy VPS clusternek, vagy mondjuk egy backup szervernek. Tehat lehet talani olyan parametereket, amik ha jok, akkor nagy valoszinuseggel jol fog teljesiteni a rendszer. Nyilvan minden rendszer egyedi, azonban mindig lehet talalni hozza egy kozel hasonlo mintat, ami - ha nem is uberalles megoldas - ad egy jo tampontot/kiindulopontot.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Egy biztos, előre kell döntenem az egyéb programokból és netes összehasonlításokból tanult minták alapján. Kevesen tehetik meg hogy egy project-et megírjanak pl PHP-ben, Python-ban és Java-ban is. Aztán meg benchmark és eldöntik melyik jobb.

Manapság PHP-ben vagyok tapasztaltabb, de a Java felé húzok.

Ez igaz PHP-re és .NET-re is. Jó, mondjuk PHP-hez a toolok fosok mind Java, mind .NET-hez képest.

Meg mondjuk az is jó kérdés, hogy kinek mi a nagy forgalmú webshop.

(Ismerős pl. azzal tud az őrületbe kergetni néha, hogy "van 5-6 db kb. napi 200 egyedi látogatóval rendelkező honlap" és olyan optimalizációs dolgokon agyal folyton, ami napi 20000 egyedi látogatónál már esetleg talán felmerül.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Arrol nem is beszelve, hogy ma mar ugy sebessegben mint memoriafoglalasban egyaltalan nincs kulonbseg a ket nyelv kozott - ha az alkalmazas jol van megirva. Valamint a Java skalazhatosaga egy picit jobb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

persicsb lentebb ezt írta:
""Igen, az a kod gyorsabb, de ez csak az egyik tenyezo. De sokkal tobb memoriat eszik:
"The x64 machine code that the translator generates consumes approximately ten times as much memory as the corresponding HHBC."
https://www.facebook.com/note.php?note_id=10150415177928920""

OK, ez nem az interpretált, hanem a fordított PHP állományokra vonatkozik.

http://hup.hu/node/117036

Ugyan ez PHP meg félig-meddig irreleváns meg úgy egyébként is, de azt hiszem, a legnagyobb bottleneck még mindig a balfasz "nem amatőr" takonygyártó kóder.

Amikor pár hetes munkával effektíve 25-30x-osára lehet gyorsítani valamit, illetve 4-5x-ös gyorsítás mellett gyakorlatilag ötödölni a gépigényt...

Másrészt brutális erőforrás van egy mai gépben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Amig standard Servlet API-t hasznalsz, addig mindegy, mi a servlet container, hiszen ha nem tetszik az A, akkor fogod es kicsereled a B-re. Pont ez a lenyege a szabvanyos API-knak :) Akar az is lehet, hogy Tomcat alatt fejleszted, de futni mondjuk Jetty alatt fog. Tok mindegy, amig szabvanyos es nem hasznal container specifikus dolgokat.

Igen, az a kod gyorsabb, de ez csak az egyik tenyezo. De sokkal tobb memoriat eszik:
"The x64 machine code that the translator generates consumes approximately ten times as much memory as the corresponding HHBC."
https://www.facebook.com/note.php?note_id=10150415177928920

A HipHop compilert azota amugy lecsereltek HHVM-re, ami egy bytecode alapu virtualis gep.
http://ajaxian.com/archives/hiphop-virtual-machine-for-php

A quercus kicsit mas tema. Az csak webes kornyezetben teszi hasznalhatova a PHP nyelvet, de nem azt csinalja, hogy a PHP kodokat JVM bytecode-ra forditja, hanem Java osztalyokra, amibol majd JVM bytecode lesz.

Valamint a quercus alapbol, hackelgetes nelkul csak Servlet kornyezetben fut, en el tudom kepzelni, hogy a Facebooknak van egy csomo nem webes kornyezetben futo adminisztrativ PHP szrkiptje is. Valamint nem csak Servletbol all a vilag, HTTP alapu kiszolgalast mashogy is lehet csinalni Java alapon, csak ahhoz sajat API kell.

Csak arrol volt szo, hogy JVM alapon fognak futni a PHP kodok. Hogy a PHP kodok szamara ki biztositja a webes infrastrukturat (azaz a CGI alapu kornyezeti valtozokat, query parametereket stb.), az teljesen mas kerdes, nem kell annak Servlet containernek lennie.

Szoval ez nem "Not Invented Here", hanem "We Need Something Else".