Why does meteor spawn lots of child processes?
looking at a htop on a server that is hosting a meteor application
i can see about 9
/root/.meteor/tools/11f45b3996/bin/node /home/panorama/panorama/panorama-demo/.meteor/local/build/main.js --keepalive
6
/root/.meteor/tools/11f45b3996/bin/node /root/.meteor/tools/11f45b3996/tools/meteor.js
and about 16
/root/.meteor/tools/11f45b3996/mongodb/bin/mongod --bind_ip 127.0.0.1 --smallfiles --port 3002 --dbpath /home/panorama/panorama/panorama
Is this normal or there is something wrong with my app?
Meteor is built as a toolkit and includes the node js process to run meteor and mongodb
The first is the instance of meteor your app will use.
The second is the meteor tool you use in the command line meteor which will be used to run/deploy/mongo, etc with your app
The third is mongodb which meteor uses with your app to store your data
This is all normal and is just run for you by the meteor tool to make running your app very easy.
Related
As we all know, we can run a meteor app by just typing meteor in a terminal.
By default it will start a server and use port 3000.
So why do I need to deploy it using MUP etc.
I can configure it to use port 80 or use nginx to route to port 80 for the app. So the port is not the point.
Edit:
Assume meteor is running on a VPS or cloud server with public IP address, not a personal computer.
MUP does a few extra things you can do yourself:
it 'bundles' the code into a single file, using meteor build bundle
the javascript is one file, and css another; it's minified, and obfuscated so it's smaller and faster to load, and less easy to decipher on the client.
some packages are also meant to be removed when running in production. For example meteorToys, the utility toolset to look up collections and much more, is not bundled into the production bundle, as per the instructions in its package. This insures you don't deploy code with security vulnerabilities (Meteor toys basically opens up client side delete / updates etc... if you're not careful)
So, in short, it installs a minimal version of your site, making sure that what's meant for development only doesn't get push to a production environment.
EDIT: On other reason to do this, is that you don't need all the Meteor build tools on your production server; that can add up to a lot of stuff, especially if you keep caches going for a while...
I believe it also takes care of hooking up to a remote MongoDB Instance (at least it used to be the case on the free meteor site) which is more scalable and fault tolerant than running on the same instance as the web server, as well as provision storage etc... if needed.
basically, to deploy a Meteor app yourself manually, you need to:
on your dev box:
meteor build bundle your app to a tar file (using the architecture flag corresponding to the OS you will use)
on the server:
install node v0.10 (or whatever is the current version of node required by Meteor)
you might have to install Fiber#1.0.5 (but I believe this is now part of meteor install already)
untar the bundle, get into bundle/programs/server/ and run npm install
run the server with node main.js in the bundle folder.
The purpose of deploying an application is that you are situating your project on hardware outside of your local machine. For example if you deploy an application on Heroku app you create a repository on heroku's systems and that code based is used to serve your application off of their servers.
If you just start an application on your personal system, you will suffer a lack of network and resource availability as well as under use of computer time at non-peak hours as your system will need to remain attentive for additional users without having alternative tasks. Hosting providers provide resources as needed, and their diverse client base allows their systems to work around the clock on a global scale.
Standard procedure to start with
meteor app -p 3000&
This works, except when I close the ssh connection, application is no more running? I have no clue why this is happening.
Awakening Edit:
I use PM2 for traditional node apps, but if I have to setup process monitors, logs, database all by myself. I could just go back to reactjs and socketio and rock it with node.
Consider use mup package from Arunoda to easily deploy and run your app in production.
You could launch meteor with nohup (no hang-up) which serves this purpose.
nohup meteor --production &
But it's not a good idea to run a site in production with meteor anyway.
What should I do to run meteor forever ?
You can use forever, a Node.js tool designed to run node apps as services.
I also want to point that forever is getting old and I've heard of better recent alternatives but it seems to still be a pretty common tool. You could also use systemd which integrates better with the UNIX service ecosystem but that's anoter story.
But first, you'll have to "demeteorize" your meteor application like this :
cd my-project-meteor
meteor bundle --directory ../my-project-node
this is going to take some time
cd ../my-project-node/programs/server
npm install
this is going to take some time too
So now you have a plain node app, that you can run with node main.js
Let me mention that it might be a good idea to use the node version used by meteor which is 0.10.29 as of meteor 0.9.1 You can install it traditionally or you could use the node version that is shipped with the meteor tool.
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/node /usr/bin/node
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/npm /usr/bin/npm
Note that this way of "installing" node + npm on your system is problematic because :
it assumes you're doing only meteor related stuff.
it is dependant on the release process of the meteor tool (you'll need to rerun these commends if the meteor tool is updated).
You can install the forever tool using npm :
-g means globally : give access to forever to all users on the system
sudo npm install -g forever
To launch your node app as a service, you can use the following command, which sets correctly some environment variables and run the app using forever :
sudo export PORT=80 MONGO_URL=mongodb://localhost/my-project-mongodb ROOT_URL=http://localhost forever start my-project-node/main.js
You can monitor it using forever stop my-project-node/main.js
Also, what's the point of using 3rd party database service like https://mongolab.com/?
When using the meteor tool, it launches a mongod process automatically for you, and the underlying node process executed by meteor representing your app connects to this mongo instance.
When we want to launch our meteor app as a node app, we have to handle the mongo stuff ourself, which kinda answer the question : why not using another service to handle it for us, they know better, right ?
Doesn't it slow down the website, because now application has to connect to their database instead of local database ?
Of course, relying on a 3rd party database service has its inconvenients, and this is one of them. Network communications will always be slower than interprocess communications taking place on localhost (this is especially true on these SSD backed cheap VPS you can find nowadays).
And how exactly do I connect to mongolab for example ?
By setting an appropriate value to the environment variable MONGO_URL, the database service provider will give you an url that corresponds to your online mongodb, this is what you need to pass to the node process in command line if you want meteor to connect to your distant database and work as usual.
If you want to launch a dedicated local mongod instance to let your application connect to it, well this is another topic but you'll have to follow these steps :
first install mongodb correctly on your server, using the reference documentation for the OS version. By correctly I mean choose the same version as meteor is using currently (2.4.9) and let it run as a service so that it will actually restart when your server reboots.
test that mongod is running by launching a client with the mongo command.
pass the correct MONGO_URL when launching your app with forever (something like mongodb://localhost/my-project-mongodb)
Understand now why meteor deploy is amazing :D
Answer copy from here
When developing with Meteor locally, one execute meteor reset locally to refresh the database.
Can one run this command on a production level app deployed on Bluemix without digging into the Mongo console?
The meteor reset command actually deletes the local mongo database files in .meteor/local. Since the database isn't stored in the application container when running in Cloud Foundry, there isn't an equivalent operation as a one liner.
Seems like your only option is to retrieve the connection credentials from your application cf env appname and then stop the application, connect with the mongo command line, and use one of the methods described in this answer to clean your data out.
For production why should I "bundle" the meteor application and not just copy
the sources on the server use the "meteor" command?
Basically what is the difference between:
"meteor bundle app.tar.gz", then installing the right version of fibers and nodejs
and extracting the archive and starting with "node main.js" the app,
and copying the project sources on the server and just writing "meteor" to start
the app?
This won't be an exhaustive list, but here are some things that the meteor command does:
creates a local database
watches on every dependent file in your app or in your packages
sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)
In contrast, bundling an app:
does not create a local database
does not spend CPU watching your files for changes
creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.
In general, deploying shouldn't be a huge pain if you use a good set of scripts.
When using a bundle:
It will not spawn meteor-mongo(Mongodb inside meteor)
No hot reloads
Meteor will not watch your files.
You can leave/quit the server without killing your app.
You can manage node processes smoothly by using pm2 or other similar npm packages.
You can decide where to put your mongoDB and decide what port to use.
You can connect to your mongodb remotely by not having to run your meteor app.
While using a copy or running meteor command in the project directory:
You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
You are letting meteor to watch over file changes which uses CPU.
When your app dies, your db dies. :)
What is best approach to have live code changes deployed to PROD.
So that
i don't have to restart my servers.
And don't want to push the entire bundle.tgz file
What are the options ??
We have a Meteor app in production - We upload the new bundle and prepare it (updating the native fibers) and restart - you have to restart the node thread.
You might say that you kick all clients, but Meteor is build to handle poor connections and will reconnect - it uses delay algorithm to help flatten out reconnects.
If the client is ready for migration the new code is then pushed.
Our app is running Meteor inside cordova and we use appcache making sure that clients can allways open our app even if offline.
NOTE: MDG is working on Galaxy - a cool and easy way of managing your own Meteor servers - so deployment would be a single line in a terminal. (eta aprox. first part of 2014)
Easy deployment to your own server (DigitalOcean, Amazon EC2, etc) can be done using meteoric.
Meteoric can setup your server and deploy latest commit to production.
I use it and it works great.