Alles anzeigenHallo liebe Community,
ich entwickle seit einiger Zeit an einem Discord Bot, bzw. auch anderen NodeJS Anwendungen. Nun bin ich endlich soweit das ich mich dazu entschieden habe hier eine Webhosting Paket zu buchen um meine Apps online bereit zu stellen.
Zuerst war ich super begeistert wie einfach alles ging und das ich ohne Configänderungen alles zu laufen gebracht habe, jetzt aber ist das Problem das der Bot immer wieder aus geht, sobald ich auf die zugehörige Domain gehe ist er zwar wieder online, aber so ganz ist das ja nicht der Sinn dahinter.
Gibt es eine Möglichkeit zu sagen das er einfach online bleibt?
Ich hoffe ihr könnt mir helfen,
viel Erfolg noch und Grüße
Die 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!)
Meines Wissens nach nicht.
Der nodeJs Support bei Plesk bezieht sich auf Webanwendungen nicht auf serverseitig dauerhaft laufende Anwendungen.
Die App wird meines Wissens nach beim Request gespawnt und nach Ende wieder beendet.
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?
Okay, ein bzw. in dem Fall meine Apps machen das genauso, nur das diese eben im Normalfall nicht direkt im Web angesprochen werden, wenn ich also den Request an den Bot auf die Website "leiten" würde und wieder zurück wäre es möglich?
Ich möchte ja niemandem seinen Speicher oder seine Leistung nehmen, das ganze sollte sich auf nicht mehr als 100 Requests am Tag beschränken, aber es ist (für mich) ärgerlich da (auch wenn es ein "Webhosting" Paket ist) nunmal da stand "NodeJS" und ich es zum größten Teil auch so nutzen wollte. Das impliziert für mich nicht gleichzeitig das ich keine dauerhafte, ohne Frontend habende Applikation laufen lassen kann.
Wäre dann am Ende mit Ruby das gleiche, ja?
Ja, das wäre bei Ruby das Gleiche: das läuft auch über eine Passenger Instanz (afaik).
Gruß, Chili
Jetzt werde ich doch mal hier im Forum aktiv.
