Hello all,
I am having trouble deciding on which option I should take to scale an app I’m building.
Searching around the web I have found the following options:
Meteor
Nginx/Haproxy balancing to scale horizontally (just like a plain web application)
Meteorhacks cluster package to scale horizontally (my choice so far) and maybe vertically with the latest release of Arunoda for multiple core support.
Phusion passenger (haven’t tried a deployment with it yet)
MongoDB
Hosted solutions such as compose.io, mongodirector, mongolab and modulus
DIY deployment
Currently I’m using DO to make my deployments but I’m wondering if using dedicated servers (ex. Hetzner) is a better option in the long term. Since I’m using meteorhacks:cluster (not the multicore setup) it makes sense to me that scaling horizontally with this option, the only problem I will have to face is mongo, please correct me if I’m wrong.
An other question is what if meteorhacks:cluster could use both options of having multiple instances on a multicore cpu and still balance between multiple server endpoints. Would that work?
And last but not least, what kind of mongo setup is considered futureproof for scaling a meteor application from 100 to 10000 concurrent user connections (considering 50-150kb publications/user)?
Thank you for taking the time to read this post, really looking forward for any suggestions and answers.
We’ve used both Ngnix and HaProxy previously. I got nothing much to blame for their performance.
We made cluster for the future and that where world is going for.
I am biased and ask you to choose cluster. Yes, you can use both multi-core and multi-server balancing.
They both works quite nicely. That’s why we keep both of them in a single package.
Mongo
For a mongo setup, you need to go for a replica set for sure. That’s where you can get the oplog support.
There is an ongoing discussion on that, check that: DIY Mongo Oplog hosting vs SaaS Compose,..?
Seems like you’ve a growing database. So, someday you need to shard you data set. Therefore try to select a shard key at this stage. Then, when you make the decision, you don’t need to think much.
Also watch for MongoDB 3.0. We are started using it at Kadira and seems like we could save a lot of disk space and removes the burden of compacting the DB every week.
(But yet, Meteor has no support for that)
Thank you Arunoda for your answer, your cluster package + mup take development in meteor to the next level. I will try a deployment with cluster in 3 multicore servers since for me is a win-win scenario.
I will follow the other discussion as I am really looking forward for mongodb 3.0 support, it looks so promising!