node.js, Threads und V8 JS Engine

[Alexander Langer]

Hallo allesamt,

Die node.js Entwickler "brï¿œsten" sich ja mit ihrem Single-Process-Modell
und sagen, sie unterstï¿œtzen aus vermeintlich guten Grï¿œnden keine Threads
und raten dazu, den Prozess zu forken. Sie verweisen auf
http://nodejs.org/api/child_process.html#child_process.fork

Was passiert da genau, wird da ein neuer V8-Prozess geforkt oder doch
nur intern ein Thread aufgemacht ?

Wo sind da die Vorteile gegenï¿œber z.B. Jython, das Java Threads benutzen
kann ? Vermutlich schneidet node.js da sogar viel schlechter ab ?

Ich frage, weil node.js vielerorts als sehr performant angepriesen
wurde, was sich, wenn ich richtig liege, als ï¿œberhaupt nicht richtig
erweist. Prozesse forken finde ich ja grundsï¿œtzlich super (siehe Chrome
Tabs). Dennoch kann die Interprozesskommunikation, wenn man sie
benï¿œtigt, recht lahm sein.

[Kai Koch]

Alexander Langer schrieb:

> Was passiert da genau, wird da ein neuer V8-Prozess geforkt oder doch
> nur intern ein Thread aufgemacht ?

Fï¿œr die Interna solltest Du auf der node-mailinglist fragen, die kï¿œnnen
das da wahrscheinlich besser antworten. Soweit ich das verstehe, nutzen
Childprozesse auf Multicore-Systeme die anderen CPU-Kerne besser aus.
Der Parrent-Process lï¿œuft auf einem Core, der Child auf einem anderen.

> Wo sind da die Vorteile gegenï¿œber z.B. Jython, das Java Threads benutzen
> kann ? Vermutlich schneidet node.js da sogar viel schlechter ab ?

Node ist keine eierlegenede Woll-Milch-Sau, aber ist Aufgrund der
non-blocking Natur fï¿œr bestimmte Sachen sehr gut geeignet.
Bei allem, wo der CPU nicht der Flaschenhals ist also z.B. Netzwerk
(Webserver, Chat, Online-Gaming-Server) hat Node die Nase vorn, da es
nicht Dï¿œumchen dreht, wenn auf Daten ï¿œbers Netzwerk gewartet wird und
mit weniger Resourcen auskommt. Um Videos oder groï¿œe Mengen Bilder
umzurechnen ist der Eventloop eher nicht geeignet, aber um deren Uploads
entgegenzunehmen und dann z.B. an die passenden C-Programme weiter zu
streamen schon.

In Node programmieren heiï¿œt:
Nicht blockend programmieren und schnell die Kontrolle an den Eventloop
zurï¿œckgeben.
Wenn Du Sachen hast die CPU intensiv sind und lï¿œnger dauern, musst Du
die entweder so programmieren, das Du bei jeden Durchgang nur einen
kleinen Teil abarbeitest oder halt Childprozesse startest. Das
ï¿œbertragen des Ergebnisses eines Childprozess in den Parrentprozess,
sollte im Vergleich zur Arbeit, die der Child erledigt, eher gering sein
sonst lohnt es sich ja gar nicht den Child auf zu machen.

Es kommt also auf das Problem an was gelï¿œst werden soll, bei manchen
Sachen bringt Node einen Geschwindigkeitsvorteil bei anderen nicht.
Wenn Dein Problem ein Nagel ist nimmst Du einen Hammer, wenn Dein
Problem eine Schraube ist nimmst Du einen Schraubenzieher usw.

--
bye, kai