Miből lesz a… Node.js?
A Node.js az egyik legdinamikusabban fejlődő projekt manapság, jelenleg a második legnépszerűbb (legtöbbek által figyelt) kód a Githubon, de sokáig első volt. A projektet indító Ryan Dahl nemrégiben közzétett egy videót, melyben beszél a kezdetekről, s ebből az is kiderül, hogy hogyan született meg ez a remek kezdeményezés.
A Node.js nekem is a szívem csücske, nagyon sok „szerver oldali JavaScript” (az idézőjel azért, mert a Node azért ennél több) megoldást kipróbáltam korábban, de messze a Node a legjobb közöttük, pedig iszonyatosan egyszerű.
Íme Ryan videója:
Talán a legérdekesebb dolog a videóban – elég könnyen ott lehet előtte ragadni! :) –, hogy Ryan egy viszonylag kis dolgot szeretett volna megoldani: valós időben kijelezni, hogy egy HTML feltöltés hol tart éppen. Na, ebből lett a Node.
Egyébként kiderül az is, hogy matekot tanult az egyetemen, de unalmasnak találta, és lelépett Dél-Amerikába (Chilébe). Aztán hat hónapnyi munkát tett bele a projektbe, bekunyerálta magát a berlini JSConfra, és a többi már történelem. :)
Ryan egyébként most hagyta ott a projekt vezetését (egy kicsit kiégett – ha jól sejtem, akkor megunta hogy a munka legkreatívabb részén túl vannak, s most a hibajavításos favágás korszak jön), de marad a Node-ot befogadó Joyentnél dolgozni.
■
Kedvenc cikkem a témában
Volt pár válasz
Amikor elindítasz mondjuk egy
Ez a megközelítés a Node-ban egy erősen töredezett kódot eredményez, amit, ha át akarsz látni, különféle programozási technikákat kell használnod. Persze van lehetőséged közben más szálakon egyéb műveleteket végezni, de ez egyrészt az általános feldolgozási sebességet csökkenti (a thread-ek számával exponenciálisan), másrészt külön tudomány a párhuzamos adatfeldolgozás megvalósítása: mikor lehet, lehet-e egyáltalán csinálni ilyet, szemaforokat figyelni, hogy a másik szál befejezte-e már a futását stb.
Nem ez a baj
Valamire ez a jó, valamire más, felesleges vitatkozni.
Annyira nem akarok
A fenti cikknek van folytatása, ahol arról értekezik a szerző, hogy a processz-, vagy az eseményalapú megközelítés a hatékonyabb.
"If you do more I/O than CPU, use more threads."
Ez a kliens megbízhatóságán
Node.js 0.6
Természetesen Node alatt is van lehetőség szálakat létrehozni (child_process.fork), ami szintén egy külön szálban fog futni, viszont itt (is) neked kell figyelned a megosztott erőforrásokra (adatbázis, fájlok stb.). És ezeket például PHP-ban elég nehéz megvalósítani hagyományos technikák alkalmazásával. Például nyitsz egy szálat (child_process.exec), ami legenerálja neked például a kisképeket mondjuk ImageMagick segítségével, majd amint ezzel végzett, akkor egy callback-ben folytathatod az alkalmazás futását, miközben az alkalmazásod már írogathat adatbázisba, másolhat / létrehozhat fájlokat stb.
thread vs. process
Igaz, elnézést attól, akit
Még pár hónapja készítettem
Az eredmények:
php + mysqlnd (unix socket): átlag 56ms
node + mysql (tcp): átlag 350ms
Majd keresek olyan mysql kiterjesztést node-hoz, ami unix socketen keresztül kommunikál, megnézem, azzal hogyan muzsikál.
Párhuzamosítás
Az eredmények a következők:
párhuzamos lekérdezések futtatásával: átlag 332ms
soros lekérdezések futtatásával (eredeti script): 380ms (ma valamiért lassabb a gépem)
Ez körülbelül 13%-os gyorsulást jelent.
Lehetne ennek az
Igen, folyamatosan