Running In Production using 'meteor --port ###' vs bundling app

help
1

This is going to be a VERY newbie question, so I’m going to have to apologize in advance!

I’m just reviewing the process to set a Meteor app into a production state by using ‘meteor bundle’, setting it up on a server and then running it using node with the ROOT_URL , MONGO_URL, PORT. I was able to get this working properly following the documentation. I currently setup a CENTOS VPS and used nginx to reverse proxy to the application. No problem. Works great.

I guess my question is; is there benefits to running this bundle versus just copying the whole application as is (like when you are developing) into my VPS and running the application using ‘MONGO_URL=‘mongodb://…’ meteor --port ####’?

Does the package size get smaller? Is there some optimization in play?

Once again I apologize for the question. I didn’t see anything in the documentation aside from it just saying “this is how you should deploy into production”, but it doesn’t really say why.

Thanks!
T

2

Hey, please read my article on the mupx deployment technique so you can setup your server easily.

Currently working on Ubuntu 14+ and Node 0.10.40. mupx will enable you to specify all of the required settings for deployment in one json file

To deploy to production really use mupx is best in my experience. If you wish to go another way, the older upstart option is possible, you will need to proxy the meteor app with nginx if you are not comfortable with this using mupx will take care of everything for you.

Good luck!

3

meteor --port xxxx is simulate environment, not real production.

4

I had the same questions when I first started with Meteor.
When you deploy it bundles everything and minifies all the code.
There is a whole toolchain which is attached to the development environment which is stripped out - for example you can’t run meteor shell or meteor mongo once deployed.
I am pretty sure that the deployed environment runs much more optimised than the development version which as @mrphu3074 said, pretty much just simulates production but is very much still development.

1 Like
5

Appreciate the the reply @cstrat ! Definitely makes sense.

6

Beyond what else has been mentioned, the meteor tool also watches all your project files and uses a lot of memory for cache, and launches a mongo for you. ps ux | grep meteor might show something like this (output condensed, %CPU taken from top):

# DESC      VSZ    %CPU  COMMAND
meteor-tool 1.8GB  3.3   ~/.meteor/.../node   ~/.meteor/packages/meteor-tool/.../tools/index.js --production
mongo       0.7GB  0.0   ~/.meteor/.../mongod --bind_ip 127.0.0.1 --smallfiles --port 3001 --dbpath ~/.meteor/local/db --oplogSize 8 --replSet meteor
app         0.8GB  0.7   ~/.meteor/.../node   project/.meteor/local/build/main.js

You’ll notice we also used --production here to still minifiy everything, for a proper comparison.

So, excluding Mongo, running the Meteor tool in addition to the build - as opposed to just the build - is using roughly almost 3x as much RAM and almost 6x the CPU. (Note, VSZ includes shared libraries so that part is erroneously counted twice).

2 Likes