Hot or not: node.js

[shredding]

Ich habe mich gestern mal ein wenig mit node.js beschäftigt und der Einstieg war auch recht einfach. Wenn man mit Actionscript / Javascript viel gearbeitet hat, ist das Eventsystem recht einfach und auch das eventgetriebene Arbeiten mit Dateien und Datenbanken ist für uns AIR Entwickler ja recht bekannt.

Was ich allerdings nicht so einschätzen kann ist, ob node.js jetzt wirklich so ein krasser Performance Boost ist.

Ich entwickle sehr gerne in PHP, schaue mir gerade Ruby und Rails an (ohne bisher richtig warm zu werden) und wüsste jetzt gar nicht was jetzt soviel besser ist.

Sehe ich das falsch: Wenn in PHP jetzt eine Datenbankabfrage kommt und der Thread warten muss, bis die wieder da ist; kümmert sich dann nicht Apache in der Zwischenzeit darum, dass andere Threads weiterlaufen? Immerhin kann Apache Mulitcore managen, node.js nicht - oder bin ich da falsch?

Hat da jemand ein paar insights / erhellendes?

Persönlich würde ich sagen, für richtig große Applikationen ist das (noch?) nichts, aber für performancekritische Dinge (wie long-polling / Comet, etwa in Chats) eine schöne Ergänzung - ich denke daran PHP und node.js etwa parallel auf einem Server einzusetzen.

Eure Meinung?

[Martin Kraft]

Vorweg: Ich bin kein Backend-Spezialist und beschäftige mich mit dem Thema nur am Rande.

Zitat von shredding

Sehe ich das falsch: Wenn in PHP jetzt eine Datenbankabfrage kommt und der Thread warten muss, bis die wieder da ist; kümmert sich dann nicht Apache in der Zwischenzeit darum, dass andere Threads weiterlaufen?

Sowie ich das verstanden habe, ermöglicht node.js Asynchronität bei der Verarbeitung eines Requests, während üblicherweise (z.B. in PHP) die einzelnen Requests jeweils synchron aber parrallel zueinander abgearbeitet werden. Letzteres sollte übrigens auch mit node.js möglich sein.

Zitat von shredding

Was ich allerdings nicht so einschätzen kann ist, ob node.js jetzt wirklich so ein krasser Performance Boost ist.

Die eigentliche Vorteil von node.js dürfte darin liegen, dass es deutlich weniger Zwischenschichten (und damit deutlich weniger OverHead) gibt, als in einer Apache+PHP-Konfiguration. Und das wirkt sich zusammen mit dem Speed der V8-Engine direkt auf die Verarbeitungsgeschwindiglkeit des Scripts aus, wie z.B. dieser Test hier zeigt:
Benchmarking Node.js - basic performance tests against Apache + PHP

Hinzu kommt (aber das ist jetzt meine persönliche Meinung), dass man sich mit einer stringenten JavaScript-Syntax und -API deutlich einfacher und nachhaltiger programmieren kann, als mit diesem Gemischtwarenladen namens PHP (in dem irgendwie alles im globalen Namespace rumgeistert und in einer babylonischen Vielfalt benannt wurde).

[shredding]

Zitat von Martin Kraft

Hinzu kommt (aber das ist jetzt meine persönliche Meinung), dass man sich mit einer stringenten JavaScript-Syntax und -API deutlich einfacher und nachhaltiger programmieren kann, als mit diesem Gemischtwarenladen namens PHP (in dem irgendwie alles im globalen Namespace rumgeistert und in einer babylonischen Vielfalt benannt wurde).

Meiner persönlichen Meinung nach ist Javascript eigentlich keine stringente Sprache; ich hab mir node.js trotz und nicht wegen Javascript angeschaut.

[Martin Kraft]

Zitat von shredding

Meiner persönlichen Meinung nach ist Javascript eigentlich keine stringente Sprache; ich hab mir node.js trotz und nicht wegen Javascript angeschaut.

Mit AS3 oder Java kann JavaScript in dieser Hinsicht sicher nicht mithalten. Aber verglichen mit PHP ist's ein Paradies

[fippo]

Sehe ich das falsch: Wenn in PHP jetzt eine Datenbankabfrage kommt und der Thread warten muss, bis die wieder da ist; kümmert sich dann nicht Apache in der Zwischenzeit darum, dass andere Threads weiterlaufen? Immerhin kann Apache Mulitcore managen, node.js nicht - oder bin ich da falsch?

Der Contextswitch zwischen verschiedenen Threads dauert. Jeder OS-Thread kostet Heapspeicher. Aber node kann auch Threads / Prozesse. Da gibt's dann die üblichen threadpool-Ansätze. Der Punkt ist, dass man von dem 1-thread-pro-connection-Modell wegkommt.

Persönlich würde ich sagen, für richtig große Applikationen ist das (noch?) nichts

roxen benutzt seit Ewigkeiten pike für den Webserver (der in den 90ern bekannter war) und ihr CMS. Das Programmiermodell ist identisch, die Sprache halt nicht Javascript sondern eine objektorientierte C-Evolution. Wenn Dir JS nicht stringent genug ist guck es Dir mal an. Ist nicht so einsteigerfreundlich und hip, aber das eventige Programmiermodell ist seit Ewigkeiten (lpmud ~1989, pike ~1994) das gleiche, was node als ihre große Innovation ausgibt:

Zitat von http://nodejs.org/about/

Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library

aber für performancekritische Dinge (wie long-polling / Comet, etwa in Chats) eine schöne Ergänzung

Chats sind mit solchen Servern nicht mehr performancekritisch wenn Du ohne Probleme ein paar hunderttausend User an einen einzelnen Server hängen kannst ;-)

[shredding]

In ASP.NET geht das auch schon länger, wie ich unlängst las.

Zitat von fippo

Chats sind mit solchen Servern nicht mehr performancekritisch wenn Du ohne Probleme ein paar hunderttausend User an einen einzelnen Server hängen kannst ;-)

Ja, klar Facebook. Aber ich hab bspw. mal viel mit LMS (Moodle) gearbeitet, da gabs sowas nicht. Auf Firmenebene so ein Chat ala Facebook wäre da cool gewesen; da sähe ich ein Anwendungsgebiet.

[Omega Psi]

Hot.

[l_ch]

verdammt hot… mach grad mit node und socket.io rum, das ist bis jetzt sehr vielverprechend.

[fippo]

Zitat von Martin Kraft

Die eigentliche Vorteil von node.js dürfte darin liegen, dass es deutlich weniger Zwischenschichten (und damit deutlich weniger OverHead) gibt, als in einer Apache+PHP-Konfiguration. Und das wirkt sich zusammen mit dem Speed der V8-Engine direkt auf die Verarbeitungsgeschwindiglkeit des Scripts aus, wie z.B. dieser Test hier zeigt:
Benchmarking Node.js - basic performance tests against Apache + PHP

Benchmarks die ich nicht selbst gefälscht habe lassen mir keine Ruhe. Also hab ich mal nodejs gegen meinen Lieblingsfisch laufen lassen. Stupid, silly benchmark mit dem Beispiel-hello-world-HTTPServer von nodejs.org und dem Standard Pike httpd.

node war marginal schneller als pike -- 10655.06 req/sec mean vs 10211.07 req/sec mean. In der Defaultversion schreibt der Pike-httpd aber auch Header wie Server: raus. Wenn man das ein wenig fairer macht kommt bei pike ein Wert von ~17000 Requests pro Sekunde raus. Das ganze bei groben 10% der Speichernutzung von node.

Innovativ hatte ich ja schon abgehakt, den Mythos mit dem Speed jetzt auch ;-)

[TheGreenFlash]

Definitiv hot nach meinen noch recht spärlichen Erfahrungen.

[creative code()]

Ultra Hot wenn ihr es in Verbindung mit haXe nutzt

[Omega Psi]

Ne, mit CoffeeScript.