I have a node js server running at modulus.io. How can I redeploy the latest version of the server without facing downtime ?
Modulus builds your app using a new container every time you deploy, so the switching can be as quick as a few milliseconds.
From their docs:
Since the bundle is already built, making the switchover from the old
version of your application to the new is very quick. The process is:
Send graceful shutdown request to old application.
Stop the old application instance.
Remove the old application instance.
Extract new application instance.
Start the new application instance.
Under normal conditions, the actual switchover takes a few
milliseconds. The amount of time it takes the application to start
serving requests then depends on how long it takes your application to
startup.
You can't, Modulus currently deploys to all servos simultaneously so the server will inevitably go down for a few seconds while it starts.
Related
I have a REST api node app.
Once its running on localhost, it runs until I stop the dev debugging, no errors.
I moved it over to my cPanel hosting, installed a node app.
It starts up the same as localhost.
But after 30 minutes being idle, it shuts down.
The next request after this, restarts the app.
There are no crash or errors in the log, just the restarting messages.
I know this is default behaviour for free hosting, like Heroku but I'm paying for this hosting package.
Does anyone know...
Is this default behaviour for cPanel hosted node apps, or is my app causing this (using too much memory or cpu for example?
Is there any settings that can be edited to change this?
According to the docs, cPanel uses something called Phusion Passenger to run Node.js. In turn, Passenger docs show a default "idle time" of 5 minutes and a default of passenger_min_instances = 1. No idea if cPanel changes the defaults, or if the hosting provider did. I would recommend contacting the hosting provider about the issue in any case, and asking about these options specifically - they may be able to help or tune the service for you.
The startup time for a node app depends on what it's doing. A rest-api could be in the milliseconds, whereas a small Ai app loading a corpus or training a dataset (which mine was) could end up being 30 seconds plus. However the quantity of users did not warrant a dedicated server, so the work-around was to call the endpoint using a CRON, keeping the app alive.
Not perfect, but this type of thing may be useful if you are using aws lambda, which calls a 3rd party service, and which charges based on time taken. Every millisecond counts.
I just want to understand if the server is fully restarted (clean state) or if it manages to migrate some of the memory data that was running from last version.
I have heard of node apps having 10k - 100k timeouts concurrently. On every new version (gcloud app deploy) of my server, will I lose all the pending functions that were not executed and I would need to reschedule all of them?
A node.js server has no memory of its own from the previous time it was run. So, if you want a server to retain some state from one time it's run until the next (like after a restart), then you have to maintain that state yourself in a persistent store and read that state back in when your server starts.
will I lose all the pending functions that were not executed and I would need to reschedule all of them?
Yes, you will lose them all. node.js does not persist timers itself. You will need to persist them yourself or use a different mechanism that does the persistence for you.
Heroku reboots servers everyday. After reboot, my node server takes around 20 seconds to load a page for the first time. Is there a way to prevent this?
EDIT: You guys seem to be misunderstanding the situation. In Heroku, even production servers must be restarted daily. This is not the same as a free server sleeping. This question is aimed more at preventing lazy-loading and pre-establishing connection pools to databases.
Old question, but in case others stumble upon it like I did
Use can use Heroku's Preboot feature:
Preboot changes the standard dyno start behavior for web dynos. Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments
You could also combine it with a warmup script like the one described in this Heroku post
Environment: Windows Server 2008
I have a Node.js and a Sails.js apps. For example, my Node.js app does something like this:
http.createServer(function(req,res){...}).listen(8000);
Both are really simple apps, but I need them available at all times. I had problems creating a Windows Service, so i created a task for each app in the Task Scheduler.
They seem to be working fine except for when the apps haven't been used for over an hour or so (not sure on the exact timing). After some time when I go to localhost:8000, my Node.js app (same with my Sails.js app) responds only after about 10-20 seconds, and in less than a second in the following requests.
I am thinking about writing another task :) - a warm-up script that will send periodic requests to keep the apps running. But there's gotta be a better way! Is there a server timeout setting in Node.js/Sails.js that can be disabled/modified?
I'm running a Node.js app in an Azure website and I'm trying to get a timer to go off every 30 seconds indefinitely. I've tried using both setInterval and node-cron but both of these stop working after about half an hour. There are no errors in the logs, and the site stays up, but the timer stops firing. I can start or recreate the timer again but it just stops working after another half an hour.
I am on the free trial period, am I running into some sort of account restriction here? Or is there some other way I should be doing this or some way to work out what is making the timer stop?
When hosting Node.js on a website (or in fact using the node.js powershell support for Cloud Services) your node process is hosted by IISNode.
IISNode will manage the lifecycle of the node process. I'm guessing it's intentionally shutting you down after 30 minutes.
You need to run node yourself in Azure if you want a process that's going to stay up. There are two options:
Use the Virtual Machines (currently in preview), and manually copy node.exe, and your javascript onto a virtual machine, and start your app manually (or as a scheduled task or something). You can use either Windows or Linux.
Use Cloud Services, and create a Worker Role which starts node as a startup task. This gives you the ability to scale as well.