Ankündigung

Einklappen
Keine Ankündigung bisher.

3,7: Knoten am andern Ende

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 3,7: Knoten am andern Ende

    3,7:
    Betrachtet man einen gewöhnlichen Request hin zu einem WebServer wie Apache oder auch Lighthttpd, der wiederum ein PHP-Skript ausliefert, so wird pro Request ein Thread erzeugt, der sequentiell seine Arbeit verrichtet. Dieses Modell hat sich seit Jahren für viele Anwendungen bewährt, hat jedoch seine Probleme beim Skalieren von Echtzeit-Anwendungen oder langlebigen Verbindungen.

    Javascript wurde bisher traditionell hauptsächlich im Browser des Benutzers ausgeführt und spielte bisher auf dem Server keine große Rolle. Dies änderte sich in letzter Zeit ein wenig durch verschiedene Projekte wie Jaxer, Narwhal oder auch CommonJS. Ein aus der Reihe tanzender und im Moment hochgehandelter Vertreter dieser Reihe ist node.js, der viele der aktuellen Probleme lösen kann.

    Node.js ist ein ausführbares Kommandozeilen-Tool, das auf dem jeweiligen System erst kompiliert werden muss. Es basiert auf prominenten Tools wie Googles V8 JavaScript Runtime sowie den Perl-Komponenten libaio sowie libev. Dabei stellt die Bibliothek im Wesentlichen Objekte zur Verfügung, über deren Methoden sich das Betriebssystem ansprechen lässt. Javascript als Programmiersprache eignet sich für das Node.js-Konzept hervorragend, da man durch anonyme Funktionen sowie Closures ein bewährtes Mittel zur Hand hat, mit dem sich Callbacks leicht definieren lassen. Zudem kann ein Javascript-Programmierer idealerweise bereits mit Events umgehen und kommt mit der Syntax zurecht.

    Ein klassischer Webserver wartet die meiste Zeit auf das Beenden von langsamen Operationen. Dies sind in aller Regel I/O-Operationen (Festplatte/Netzwerk), da diese wesentlich langsamer sind als Operationen, die im Arbeitsspeicher stattfinden. Im klassischen Fall einer PHP-Anwendung würde der Client solange auf den Content warten müssen (ohne Caching-Mechanismen), bis alles komplett abgearbeitet wurde. In einer Operation von 10 Datenbank-Queries a 10ms wären das bereits 100ms.

    Node profitiert hier im Vergleich mit der klassischen Applikation von seinem grundsätzlich asynchronen Charakter. Sofern die Datenbank parallele Requests abarbeiten kann, werden alle 10 Anfragen nahezu parallel bearbeitet, womit die langsamste Anfrage die Reaktionszeit bestimmen würde. Stark vereinfacht würde – auf das obere Beispiel bezogen – ein Durchlauf in Node.js nur etwa ein Zehntel der Zeit beanspruchen. Aber warum?

    Die Antwort liegt im Prinzip der Bibliothek. Diese profitiert davon, dass Javascript von vornherein für Events erdacht wurde und läuft im Unterschied zum klassischen Thread der Webserver-Anfrage in einem einzigen Event-Loop ab, sprich in einem einzigen Thread oder einfach gesprochen in einer ewigen while-Schleife. Da jede Operation einen asynchronen Request darstellt, bringt node.js auch seinen eigenen Observer mit. Node.js' „EventEmitter“ abstrahiert hierbei das Binding, Unbinding oder auch Feuern/Triggern von Events und kann an sehr viele Operationen angebunden werden (inkl. aller I/O-Operationen). Dieser Loop beinhaltet beliebig viele Objekte und wird permanent durchlaufen. Jeder Request an das Betriebssystem läuft für den Programmierer grundsätzlich asynchron ab. Beim nächsten Durchlauf durch den Event-Loop registriert node.js jegliche Veränderung und feuert die jeweiligen Events, die wiederum definierte Callbacks aufrufen.
    Oder kurz und knackig beschrieben:
    • Nie auf das Ergebnis warten, sondern einfach weitermachen.
    • alles parallel mit Ausnahme des Codes
    • Ziel ist es hierbei, eine Programmierumgebung zu schaffen, die nie blockiert und gleichzeitig auf unglaublich viele Anfragen reagieren kann.


    Node.js' event-basiertes Modell macht es dem Entwickler einfach, Applikationen in Echtzeit zu skalieren, ist jedoch zunächst sehr ungewohnt und bringt eine andere Komplexität in eine vorher klar strukturierte Anwendungsstruktur, an die man sich vielleicht erst gewöhnen muss.

    Ein node.js-Skript beginnt immer mit einem require-Teil der Module bzw. Addons am Anfang des Skripts. Dies ist der einzige Teil der Anwendung, der nicht parallel ausgeführt wird. Es gibt bereits einen sehr großen Teil an (externen) Modulen mit, so dass man sich nicht um alles selbst kümmern muss (und auch nicht sollte). Eine Liste der Module kann man dem Projekt-Wiki entnehmen.
    Alternativ kann man dazu ihren Paketmanager npm verwenden, der das Installieren von Modulen per Terminal vereinfacht (npm install modulname).

    Da die Bibliothek noch keine 2 Jahre alt ist, existieren vielleicht noch nicht für alle benötigten Schnittstellen Module bzw. Addons, mit denen man gerne arbeiten möchte. Sollte man in dem Fall dennoch mit node.js arbeiten wollen, heißt es in jedem Fall selbst Hand anlegen. Teilweise lassen sich auch in C geschriebene Bibliotheken einbauen. Falls das alles nicht in Frage kommt, sollte man noch die Finger von node.js lassen.

    Datei-Uploads und -Downloads sind Streams, können aber vom HTTP-Protokoll in der Abstraktion der Frameworks nur in ihrer Vollständigkeit betrachtet werden. Node.js macht es z.B. möglich, hochgeladene File-Chunks parallel weiterzustreamen oder zu bearbeiten.

    Node.js bietet unglaubliche Möglichkeiten, einige interessante Ideen-Fundstücke habe ich euch aufgelistet.
    • Web-Sockets und node.js => Ajax-Chat
    • Client-Loadbalancer
    • Flash-Alternative für File-Uploads in Echtzeit
    • (Formularvalidierungs-) Logik zwischen Client und Server hin- und herschieben
    • Inkrementelles Rendering von Seiteninhalten über „zerstückelte“ HTML-Fragmente, asynchrones Ausliefern einer HTML-Datei



    Euer Weihnacksmann

  • #2
    Toll!

    Gibt es zu irgendeinem dieser JavaScript-Interpretern ein Beispiel, wo man sieht, wie man Validierungen nur ein einziges mal programmieren muss, diese Validierung aber client- und server-seitig ausgeführt werden kann?

    Serverseitig natürlich in Verbindung mit PHP. PHP müsste als zur Validierung die JavaScript-Funktion aufrufen können.

    Auch noch interessant ist SpiderMonkey. Hier kann man ganz normal in PHP programmieren. Im Hintegrund arbeitet dann aber ein JavaScript-Interpreter.

    Kommentar


    • #3
      Jenachdem wo man es einsetzen will, wäre die Richtung wohl eher umgekehrt, man validiert in PHP und JS schickt während den Eingaben Ajax-Requests an ein php-script das einem z.b. eine JSON-Variante der Fehlermeldungen zurückgibt und die dann einsetzt.

      Denn Dinge wie nodejs und co hat man nicht mal eben auf dem webspace laufen.
      [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
      | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

      Kommentar


      • #4
        Ich würde das gerne umgekehrt machen.

        Zuerst auf der Browser-Seite prüfen. Dann nach dem Absenden des Formulars auf der Server-Seite.

        Dadurch, dass ich zuerst nur rein auf der Browser-Seite prüfe habe ich 3 Vorteile:

        - Ich quäle den Server nicht durch AJAX-Requests.

        - Dadurch dass ich schon auf der Clientseite prüfe, entfällt unnötiger Internet-Traffic und eine unnötige Server-Belastung, wenn dann PHP erst einen Fehler erkennt.

        - Kann ich auf Client- und Server-Seite die gleiche JavaScript-Funktion zum Validieren verwenden, erspare ich mir Arbeit.

        Allerdings besteht natürlich auch die Gefahr, dass ein Hacker sofort eine Betriebsanleitung in der Hand hat, falls die Validierungsfunktion mangelhaft sein sollte.

        Kommentar


        • #5
          Zu node.js gibt es auch ein CCC-Podcast: http://chaosradio.ccc.de/cre167.html

          Kommentar


          • #6
            Zitat von coola Beitrag anzeigen
            Allerdings besteht natürlich auch die Gefahr, dass ein Hacker sofort eine Betriebsanleitung in der Hand hat, falls die Validierungsfunktion mangelhaft sein sollte.
            Nicht nur das, er kann auch sämtlichen Code manipulieren und damit jegliche Validierung umgehen.
            Programming today is a race between developers striving to build better idiot-proof programs, and the universe trying to produce better idiots. So far, the universe is winning.

            Kommentar


            • #7
              Nicht, wenn sie serverseitig erneut erfolgt (wies oben steht).
              [COLOR="#F5F5FF"]--[/COLOR]
              [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
              [COLOR="#F5F5FF"]
              --[/COLOR]

              Kommentar


              • #8
                Hoppla, habe "Dadurch, dass ich nur rein auf der Browser-Seite prüfe habe ich 3 Vorteile:" gelesen.
                Programming today is a race between developers striving to build better idiot-proof programs, and the universe trying to produce better idiots. So far, the universe is winning.

                Kommentar

                Lädt...
                X