• Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Welche Sprache für Daemon/Server?

SeKrebs

New member
Mal so in die Runde gefragt: Welche Sprache würdet ihr für einen Daemon, bzw einfachen (nicht-HTTP) Server verwenden? Aus der Vergangenheit hab ich noch mit genommen, dass PHP für langlaufende Prozesse ... eher mittel geeignet ist. Zudem kenne ich jetzt auf Anhieb keine brauchbaren Server-Socket Libraries. Alternativ wäre noch Ruby und Python denkbar. Würde aussm Bauch eher zu Python tendieren (hat irgendwie nen anderen Coolness-Faktor :rolleyes:).

C fällt kategorisch raus :D. Java wäre noch denkbar... :X
 

DennisBecker

Super-Moderator
Neben Python und Java würde ich noch Node.js einstreuen. Node.js kann auch gut mit Sockets umgehen soweit ich gesehen habe. Zwar waren das primär UDP Sockets über dgram, aber TCP Sockets werden über das net Modul implementiert.

Ansonsten hängt es ja auch vom eigenen Geschmack und Einsatzzweck ab :)


PS: Perl würde ich nicht empfehlen!
 

SeKrebs

New member
Neben Python und Java würde ich noch Node.js einstreuen. Node.js kann auch gut mit Sockets umgehen soweit ich gesehen habe. Zwar waren das primär UDP Sockets über dgram, aber TCP Sockets werden über das net Modul implementiert.
Guter Punkt. Da es eh auch nen stückweit darum geht, dass ich mal wieder mit was rumspielen wollte, würde sich das anbieten. Eventuell wäre sogar UDP auch nicht falsch (siehe nächster Punkt ;))
Ansonsten hängt es ja auch vom eigenen Geschmack und Einsatzzweck ab
Der Einsatzzweck existiert eher so semi. Ist nur ne grobe Idee :X Seh ich später, obs irgendwie Sinn macht
PS: Perl würde ich nicht empfehlen!
:D
 

ice-breaker

New member
Ich würde da auch Node.js vorschlagen. Es ist einfach, hat mittlerweile eine wahnsinnig große Community und ist trotz der echten simplen Entwicklung verdammt effizient.

Ansonsten würde ich noch Erlang in den Topf werfen, falls der Zweck mehr Richtung High Availiability, Fehlertoleranz, Multi Core und Soft Realtime geht. Und natürlich auch bei verteilten Systemen.
 

DennisBecker

Super-Moderator
Perl skaliert irgendwann nicht mehr mit mehr CPU Leistung & RAM. Alleine schon, dass Perl eine berechnung macht wie X Anzahl Variablen*(N GB RAM / festgelegter Wert) * 10 ist schon bissl bekloppt. Zudem neigt man in Perl dazu, Code zu schreiben, der zwar knapp ist, aber schlecht lesbar & wartbar. Perl scheitert daher aus meiner Sicht in punkto Effizienz. Da würde ich eher zu Python greifen.

Wenn du Perl mit einbeziehen willst musst du auch PHP mit einbeziehen. Im Bezug auf Effizienz gewinnt dann aber PHP eindeutig. Mit den neuen OOP Modulen aus CPAN gibt es wenigstens etwas, wodurch Perl sich mehr wie eine OOP Sprache anfühlt.


PS: Ich kenne nur Perl 5.8+, wie es bei Perl 6 aussieht weiß ich nicht. Gibt es davon mittlerweile einen RC1?
 

ice-breaker

New member
Im Gegensatz hat Python noch immer den Gloabl Interpreter Lock. Also kann auch nur ein Thread gleichzeitig Python Code ausführen. Bezogen auf die Skalierung auf mehrere Cores ist also Python auch nicht die beste Wahl.

Node.js hat das Problem, dass es von Natur aus nur singlethreaded ist. Da muss man die Arbeit dann durch Worker auf mehrere Cores verteilen, also auch nicht optimal. Genauer gesagt läuft der JavaScript-Teil nur in einem Thread, das ganze I/O usw. läuft im Hintergrund in mehreren Threads.

Für wirkliche Effizienz in Multithreading gibt es nur wenige Möglichkeiten. Ganz sicher bin ich mir nur bei Java, C und Erlang. Die Frage ist eben immer inwieweit wirklich die Software skalieren muss. Am Beispiel von Node.js sieht man schon, wie abartig schnell auch Software auf einem Core arbeiten kann, wenn das Programmiermodell stimmt. Hand-Crafted Threading in Java oder C wird aber alles in die Tonne stecken. Im Gegensatz dazu ist es aber auch extrem fehleranfällig. Also Mutexe sind nicht das Problem, sondern die Thread Visibility Garantien. Oder man nutzt ein Actor-Framework, welches dem Modell von Erlang nachempfungen ist, so wie Akka für Java/Scala.

Ja, ich habe diese Suche bereits hinter mir. Vor dem Problem stand ich nämlich auch schon.

Nachtrag:
Mir fällt da gerade noch das Vert.X Framework fpür Java ein, das ist ein Node.js auf Java-Basis und kann alle Cores ausnutzen. Allerdings ist die Community davon wirklich sehr klein, es ist eben schwer in dem Punkt dann mit Node.js zu konkurrieren.
 
Zuletzt bearbeitet:

SeKrebs

New member
ice-breaker schrieb:
Im Gegensatz hat Python noch immer den Gloabl Interpreter Lock. Also kann auch nur ein Thread gleichzeitig Python Code ausführen. Bezogen auf die Skalierung auf mehrere Cores ist also Python auch nicht die beste Wahl.
Kannst du das mal näher Erläutern? Threads laufen nicht parallel? :confused:

ice-breaker schrieb:
Node.js hat das Problem, dass es von Natur aus nur singlethreaded ist. Da muss man die Arbeit dann durch Worker auf mehrere Cores verteilen, also auch nicht optimal. Genauer gesagt läuft der JavaScript-Teil nur in einem Thread, das ganze I/O usw. läuft im Hintergrund in mehreren Threads.
Das lässt sich in PHP sogar nachstellen: Streams lassen sich in den Non-Blocking-Mode schieben, was heißt, dass man zB Request absetzen kann (zB an einen anderen Prozess zB via Socket zB via UNIX-Socket .... uff ^^). Vorausgesetzt wir meinen jetzt das selbe :D Jetzt versteh ich aber nicht mehr so ganz, was an Node.js eigentlich so gehypt wird, wenn es auch nur eine weitere serverseitige Script-Sprache ist :X

Und #perl: Ehrlich gesagt ist mir das zu freakig :X
 
Zuletzt bearbeitet:

ice-breaker

New member
Kannst du das mal näher Erläutern? Threads laufen nicht parallel? :confused:

Nein, tun sie nicht. Python hat einen GIL (Global Interpreter Lock), der verhindert, dass 2 Threads parallel laufen können. Das Memory Modell von Python, bzw. die Implementierung im Interpreter, ist nicht threadsafe. Aus diesem Grund verhindert Python, dass 2 Threads parallel arbeiten können. Wenn du also 2 Threads hast, die beide rechnen wollen, darf es nur einer. Das Threading in Python macht also nur Sinn, wenn z.B. ein Thread in nem blocking IO-Aufruf steckt, da er dann sowieso nicht rechnen kann und der andere munter rechnet. Die Anzahl der blocking Threads kannst du beliebig erhöhen. Aber es werden nie 2 Threads gleichzeitig arbeiten.

Jetzt versteh ich aber nicht mehr so ganz, was an Node.js eigentlich so gehypt wird, wenn es auch nur eine weitere serverseitige Script-Sprache ist :X
Es ist das Programmiermodell, dazu muss ich aber weiter ausholen.
Wer schonmal ernsthaft Multithreading mit Java oder C betrieben hat, weiß welcher Graus das ist. Im Prinzip ist es ganz einfach, dass man einfach Locks/Mutexe nutzt um wechselseitigen Ausschluss von Code zu garantieren. Umso mehr man solche Locks/Mutexe hat, umso höher ist aber die Wahrscheinlichkeit von Deadlocks, da Methode A den Lock X hält und Methode Y in irgendeinem Modul aufruft welches den Lock Y haben will. Zusammen mit noch einer Anzahl weiterer Locks in anderen Threads entstehen so schnell Deadlocks, die man einfach von vornerein nicht sinnvoll erahnen kann, weil eben jedes Modul sein eigenes Locking hat.
Aber Locks sind nur das eine Problem, viel schlimmer wird es ist mit der Memory Visitbility. Wechselseitigen Ausschluss kann man leicht erreichen, aber wie garantiert man, dass mein Thread A die Variable x sehen kann, die gerade Thread B geschrieben hat? Und da fängt es an in Threading eklig zu werden, denn diese Fehler passen sehr oft. Auf dem Entiwcklungsrechner funktioniert alles super, weil der Fehler auf Grund der Architektur nicht eintreten kann (z.B. Shared Caches). Auf dem Server fliegen aber nach 3-5 Tagen immermal NullPointerExceptions, die man nicht nachvollziehen kann, das dürfte doch gar nicht auftreten... Doch es darf, denn bei der Architektur der CPU des Servers ist dies eben möglich, nur auf deinem Rechner nicht. Und dann beginnt die Suche nach dem Bug, und die wird besonders kompliziert, da der Fehler eine Race Condition ist und somit nur selten auftritt und vor allem nicht vorhersehbar.
Das zu den Schwierigkeiten normalen Threadings.

Am liebsten würde man also alles single-threaded implementieren oder ein Programmiermodell haben, bei dem diese Fehler nicht möglich sind. Und genau hier kommt Node.js: Der Code von Node.js,also oder Userland-JavaScript-Code, läuft nur in einem Thread. Ein Thread, nicht weniger, nicht mehr. Memory Visibility Garantien sind kein Problem, das kennt JavaScript nicht, auf Grund des Singlethreaded-Modells kennt der ausführende JavaScript-Code immer den aktuellen Zustand. Das Problem sind natürlich nun blockende Aufrufe wie I/O-Operation, die würden den ganzen Node.js-Prozess "lahmlegen". Aber hier kommt einem zu gute, dass JavaScript im Browser auf ein EventModell setzt, welches man auch auf ServerSoftware übertragen kann, und das macht JavaScript. Jede blockierende I/O-Operation ist non-blocking und man übergibt dem Aufruf einen Closure, der ausgeführt wird, wenn das System im Hintergrund die Operation abgearbeitet hat. In der Zwischenzeit können aber andere Events ausgeführt werden. Es kann also Core dauerhaft mit dem JavaScript Userland-Code laufen und das ganze I/O-Zeug usw. passiert im Hintergrund. Keine Probleme mit Threading mehr. Das Modell wird hier nochmal genauer erklärt. Ich kann also, in begrenztem Maße, mehrere Cores ausnutzen und trotzdem meinen gesamten Code singlethreaded schreiben. Mein eigener Code wird singlethreaded ausgeführt, die Engine macht aber I/O und vieles andere in mehreren Threads im Hintergrund. Erst wenn mein Code auch auf mehreren Cores laufen soll, habe ich ein "Problem". Aber hier greift dann einfach der normale Linux-Ansatz: Ich starte noch einen Node.js-Prozess und gebe dem eben Arbeit. Das funktioniert in Node.js dann über das Cluster-Modul oder man macht es über JavaScript-Worker-Prozesse wie auch im HTML5-Standard.

Aber Node.js ist eben trotzdem dem singlethreaded-Ansatz rasend schnell, denn nur wenig der Ausführung eines Programms ist wirklich userland-Code, das meiste wird I/O oder Sleeptime sein. Und dafür ist Nodejs konzipiert. Number Crunching ist damit dann eben nicht möglich.
Ich denke so richtig verstehen tut man den Hype Node.js erst wenn:

  • man schon die Gotchas manuellen Threadings gelernt und vor allem Hassen gelernt hat
  • man es mal ausprobiert hat und sieht mit wie wenig Code man Dinge extrem effizient und mit wirklich guter Skalierbarkeit umsetzen kann
  • man es mal ausprobiert hat und sieht mit wie wenig Code man Dinge extrem effizient und mit wirklich guter Skalierbarkeit umsetzen kann
  • ...

Node.js passt eben in eine spezielle Problemdomäne: Daemons oder generell Server. Und da vor allem Dinge, die sich z.B. mit PHP nicht umsetzen lassen. Ein ServerSentEvents-Server mit PHP? Na viel Spaß, das wird nicht effizient gehen. Für normale Webseiten, wie wir mit dem Zend Framework umsetzen, ist es aber imho keine Alternative. Da ist das Event-Modell dann einfach zu umständlich, aber für "kurzen" Code mit einer großen Skalierbarkeit oder irgendeine Software wie ServerSentEvents bei der die HTTP-Verbindungen miteinander kommunizieren müssen oder langlebig sind ist es genial.


Wie gesagt, man muss es einfach mal ausprobiert haben.
 

SeKrebs

New member
Nein, tun sie nicht. Python hat einen GIL (Global Interpreter Lock), der verhindert, dass 2 Threads parallel laufen können. Das Memory Modell von Python, bzw. die Implementierung im Interpreter, ist nicht threadsafe. Aus diesem Grund verhindert Python, dass 2 Threads parallel arbeiten können. Wenn du also 2 Threads hast, die beide rechnen wollen, darf es nur einer. Das Threading in Python macht also nur Sinn, wenn z.B. ein Thread in nem blocking IO-Aufruf steckt, da er dann sowieso nicht rechnen kann und der andere munter rechnet. Die Anzahl der blocking Threads kannst du beliebig erhöhen. Aber es werden nie 2 Threads gleichzeitig arbeiten.
Kennt Python nativ Prozesse? Ohne shared memory sollts ja kein Konfliktpotential geben und somit auch kein Grund für Locks.

Es ist das Programmiermodell, dazu muss ich aber weiter ausholen.
tl;dr :X Ich les später aber ;)
 

christian1987

New member
man es mal ausprobiert hat und sieht mit wie wenig Code man Dinge extrem effizient und mit wirklich guter Skalierbarkeit umsetzen kann


Das ist das Standardargument der Node.js Nutzer und ehrlich gesagt, entspricht das nicht mal der Wahrheit. Der Apache Server beispielsweise startet für jeden HTTP Request einen neuen Thread. Das Betriebssystem verteilt dann die Threads auf die entsprechenden CPU-Cores. Damit ist Node.Js sehr weit von der Effizienz eines Apache Servers entfernt.

Frage steht weiterhin im Raum: Wozu Node.Js?
 

ice-breaker

New member
Kennt Python nativ Prozesse? Ohne shared memory sollts ja kein Konfliktpotential geben und somit auch kein Grund für Locks.
Kennt es, aber dann verliert es doch jeden Vorteil. Die Kommunikation der Prozesse ist relativ aufwendig wenn man kein shared memory hat. Oder Aktoren wie Erlang.




Das ist das Standardargument der Node.js Nutzer und ehrlich gesagt, entspricht das nicht mal der Wahrheit. Der Apache Server beispielsweise startet für jeden HTTP Request einen neuen Thread. Das Betriebssystem verteilt dann die Threads auf die entsprechenden CPU-Cores. Damit ist Node.Js sehr weit von der Effizienz eines Apache Servers entfernt.

Ist das das neue Verhalten von den MPM Workern? Weil ich kenne nur das ein Prozess pro Request Modell von Apache.

Generell unterliegst du aber einen falschen Annahme von Node.js ;) Node.js soll nicht einen Webserver ersetzen. Und wird auch nicht schneller als dieser sein können, niemals. Denn überlege einfach mal: Wenn Apache auf Threads aufbaut, bauen sie auf das effizienteste Verfahren für Skalierung über mehrere Cores, aber auch das am schwersten zu entwickelnde. Und genau das will Node.js ja nicht, es soll "dead simple" sein.
Du musst Node.js eber als Konkurrenz für Apache+PHP als z.B. Webservice sehen. Da outperformed Node.js eben PHP um Längen. Einfach weil die V8 Engine schon Meilen schneller ist als PHP. Und wenn du z.B. PHP an nen Apache oder Nginx Webserver anshcliest, hast du eben eine Begrnzung durch deine maximalen 30 PHP-FastCGI-Prozesse. Bei Node.js gibt es das nicht, Node.js hat einen eingebauten eigenen Webserver, und auf Grund des non-blocking Verhaltens von Node.js kannst du eben auch zehntausend Requests parallel bearbeiten, PHP würde dir da den Speicher killen.


Frage steht weiterhin im Raum: Wozu Node.Js?
Für die Probleme wo es Sinn macht. Einen eigenen Webserver wird wohl niemand entwickeln. Was ist aber mit einem Webservice der tausend Reuest parallel bearbeiten können muss? Oder ein Long-Polling-Webserver? Das kannst du in PHP nicht bauen, ein Apache kann das auch nicht, da es Aufgabe einer dahinterliegenden Anwendung ist. Und da kommt dann eben die Wahl welche Sprache oder Framework man verwendet, und Node.js ist einer der Kandidaten.
Node.js ist keine Allheil-Lösung wie es in dem Hype oft propagiert wird, aber wenn man ein passendes Problem hat, ist es wirklich genial. Ich werfe mal das von Mozilla entwickelte "Browser Querst"-MMO im Browser ein, ein Node.js-Server - und der Code ist sehr simpel.
 
Zuletzt bearbeitet:

DennisBecker

Super-Moderator
Wir haben letztes auf der Arbeit ein Programmierspiel mit 5 Teams gespielt. Es geht dabei um Das Spiel Mäxchen, oder Mia oder Meier. 3 Teams haben ihren Bot in Java geschrieben, eines in Python und eines in PHP. Die Kollegen, die das auf der Sokrates kennengelernt hatten, hatten ihre Bots in Node.js geschrieben. Und ich muss wirklich sagen, die Node.js Bots brauchten den wenigsten Code - sie brauchten auch keine Endlosschleife ;) Das ganze sah auch viel strukturierter aus.

Ich kann euch nur empfehlen, das "Spiel" auch mal mit den Entwicklerkollegen zu spielen. Vorher sollte man aber das Kata machen, damit jeder eine Basis für den Client hat, denn der Einstieg ist nicht immer so Trivial. Währned das Python Team als erstes eine Connection hatte, brauchte das PHP Team am längsten, bis es auf demselben Port gelauscht und geschrieben hatte. Dafür war das PHP Team beim Kata dann doch am schnellsten :D
 

christian1987

New member
Was ist aber mit einem Webservice der tausend Reuest parallel bearbeiten können muss?
Die werden doch gar nicht parallel abgearbeitet (Im Gegensatz zu Apache). Node.js ist Single-Threaded! Somit kann immer nur ein Callback auf einmal ausgeführt werden. Die anderen müssen warten.

Ich weiß aber schon was Du sagen willst. Ich schaue mir Node.js jetzt auch mal an.
 
Zuletzt bearbeitet:

ice-breaker

New member
Ich weiß aber schon was Du sagen willst.
Korintenkacker :p Ohne eine CPU mit tausend Kernen, würde es sowieso nicht parallel gehen :cool:


Für die anderen:
christian1987 hat Recht, dass nur ein Callback gleichzeitig ausgeführt wird und somit auch nur ein Request gleichzeitig abgearbeitet werden kann. Aber die Ausführungszeit des JavaScript-Codes ist verschwindend gering, 99% der Zeit wird für die Bearbeitung eines Requests für I/O draufgehen (z.B. Datenbankabfragen). Und in der Zeit kann eben ein anderer Callback laufen.
 

ice-breaker

New member
@christian1987: jein, also nicht in einem Operationsmodus bei dem beide miteinander kommunizieren mussten. Aber DennisBecker hat bereits eine Art der verdächtigen aufgezählt, wie man verschiedene Systeme verbinden, die andere wären dann Message Queues.
 

christian1987

New member
Na ja, wenn ich node.js als Api betreibe, brauche ich es auch erst gar nicht einzusetzen, weil es dafür einfach sinnvollere Alternativen gibt...

Über so Sachen wie message queues müsste man mal nachdenken. Aber selbst dort gibt es andere - und evtl. auch sinnvollere - Wege (cometD, html5 websockets, etc.)
 
Zuletzt bearbeitet:
Oben