Alles anzeigenDie Anwendung bleibt eine Weile noch aktiv, bevor sie sterben geschickt wird (um Resourcen frei zu geben). Wenn neue Netzwerkverbindungen eintreffen, dann bleibt die Anwendung aktiv; es sei denn der Server braucht Platz für andere, dann könnte ich mir vorstellen, dass die Anwendungen auch mal vor dem Timeout gekillt werden. (Scheduling is a bitch!)
Ich habe auch mal hier gesammelt was ich weiß/zu wissen glaube... Es sind viele Fragezeichen, aber vllt kann man die ein oder andere Antwort hier mal sammeln.
Vllt kann netcup.de dann auch einen Wikieintrag draus basteln?
Davon habe ich auch schon gehört. Das installierte Node.js läuft scheinbar in sowas hier: Passenger - Fundamental Concepts
Als Kunde hat man leider keinen Einfluss auf die Rahmenparameter. Manche Sachen sind ein wenig unintuitiv. Scheinbar wird auch der Shutdown anders als Standard gehandhabt: Node.js - beforeExit, Node.js - exit werden durch den Passenger Loader hier anders initialisiert und getriggered. Das hat dann Implikationen auf das Ausführungsverhalten und ich habe bisher keine Dokumentation über bestimmte Themen wie:
- Application State: Wie viel Zeit hat eine Anwendung, um State zu persistieren? Soweit ich das verstanden habe, muss das dann alles synchron passieren (z.B. fs.writeFileSync())
- Wie viele Instanzen startet Plesk maximal parallel? Sieht man das im Plesk?
- Was passiert, wenn der Prozess im "Shutdown" ist und es kommt eine neue Verbindung rein? Soweit ich das verstanden habe, startet dann "magisch" eine neue Instanz. Was aber passiert mit dem "State"? Wie ist da gedacht zu synchronisieren? Theoretisch muss man das dann durch FileLocks und Datenbank garantieren und kann es nicht über Nodejs selbst (weil man kein "Event" oder so zwischen den Instanzen bekommt)
- Kann man wirklich sagen, dass "hart Abschießen" die beste Möglichkeit zum "Sparen" ist? Meiner Einschätzung nach sollte lange Inaktivität zum ausswappen (also Rausschreiben auf einen Festspeicher; oder in-memory-compression, etc.) führen. Eigentlich ist der Charme einer Node.js Anwendung ja, dass man den State (anders als bei "klassischem" Php) nicht ständig zwischen den Anfragen "rekonstruieren" muss und in JS direkt cachen kann, mehrere ClientConnections in einem Kontext halten kann (Stichwort: websockets und server initierte Replies). WENN also der Startup der Anwendung komplex und lange dauert, weil vllt bestimmte Resourcen geladen werden müssen (die vllt in der Anfrage gar nicht gebraucht werden!), aber die Anfrage selbst nicht teuer ist, dann ist es fatal für die Einsparung einen Shutdown und Restart zu erzwingen. Zudem stiege dann auch die Latenz für den Client.
- Was passiert, wenn ein "Cleanupjob", z.B. getriggered durch einen Cronjob mal länger braucht?
- Wie viele der Passenger Optionen siehst du in Plesk?
Bei meiner Ausführung könnte man sich jetzt wundern, warum Netcup auf solch ein System für node.js setzt, wo es doch scheinbar nicht allzu sehr dem "realen" node.js Gedanken folgt. Man muss aber hier auch ein paar Dinge berücksichtigen:
- Es ist noch "recht neu"
- Plesk ist etabliert und war hier früher schon im Einsatz; es ist einfacher eine neue Technologie durch ein Plugin nachzurüsten, als sich in risikoreiche ungewisse Gewässer zu wagen
- Es muss wirtschaftlich für den Hoster Netcup sein: Man kann nicht einfach mal eben ein eigenes Managementsystem für eine noch junge Webtechnologie aus dem Boden stampfen und erwarten, dass das schnell und vor allem sicher funktioniert.
- Auch wenn netcup im Angebot nicht direkt die Hosen runterlässt, dass node.js auf Sparflamme brennt: Man muss hier im Forum nur mal nach Fragen wie dieser suchen und stellt fest, dass das (noch) nicht viele sind. Das heißt: falls jmd wirklich node.js benutzt, dann ist es bisher wenigen aufgefallen, dass ihre Anwendungen in solchen Fällen hops gehen und dann ist das aus rein wirtschaftlichen Gründen auch okay.
- Ich bin sicher, dass sich da nochwas bei Plesk und somit auch bei netcup tun wird.
- Es ist "nur" Webhosting. Klar, wegen einem Bot, der vmtl die meiste Zeit schläft einen vServer zu bezahlen klingt echt ein bisschen overkill (wenn man es nicht selbst macht), aber vllt ist das jetzt auch grade der Präzendenzfall, der den Stein ins Rollen bringt?
Ja, das wäre bei Ruby das Gleiche: das läuft auch über eine Passenger Instanz (afaik).
Gruß, Chili
Wow was für eine ausführliche Antwort, sehr gut zusammengefasst, eine genauere Beschreibung dessen würde ich mir auch wünschen, ich bleibe zwar dabei, weil ein vServer overkill ist, aber Webhosting nicht wirklich (für mich) funktioniert, was natürlich ärgerlich ist.
Könnte es evtl sein das die Anwendung durch einen Fehler (glaub müsste im apache error log zu finden sein) abbricht und deshalb erst beim öffnen der Domain neu gestartet wird?
Also hab noch kein derartiges Verhalten auf meinem PC festgestellt, dementsprechend glaube ich nicht das es daran liegt und die Antwort der vorherigen schon Sinn ergeben.
Grüße,
Shrumpf
