Meteor Galaxy: Is it better performance running 2 - 512MB containers or a single - 1GB container? Cost is the same

deployment
1

I just signed up for Galaxy and am using compose for my database.

The pricing is such that the 512MB container is half the price of the 1GB container.

I have choosen the 1GB container, but am wondering if I should choose the 512MB container and run 2 of them? What are the pros and cons of each choice?

For the purposes of this question my app can generalized as a notes app, where people keep notepads, and can collaborate together on documents.

Thanks

2 Likes
2

I answered over on Crater since it was posted there: https://crater.io/posts/5dvmXeo3hcnQPizTj/meteor-galaxy-is-it-better-performance-running-2-512mb

1 Like
3

I would say it depends on what the limitations of your app are.

For example, if your application is CPU bound then having the extra ECU in the larger instance will lead to a more responsive app.

That being said, as Josh pointed out, it’s always great to have a minimum of 2 containers running your app in case one goes down.

4

I think it’s a good question, because Meteor is in general more CPU intensive than memory intensive (because of its magic) yet Galaxy containers are focussed on ram. I’ve been running Meteor apps just fine on Digital Ocean 512mb containers, but they are small apps.

For a small app I’d first go for a 1x512mb instance and start monitoring that with Kadira & Pingdom.
When you’re running out of memory / your app is slow / crashes, add another 512 instance and see if that solves your problem. If you still have issues take the 1gb, then 2x1gb and keep scaling like that.

Unless money is not an issue, then just take 2x1gb or more from start.

If money is an issue, start with Digital Ocean. You can also build your own Galaxy on Digital Ocean

5

This actually isn’t 100% true. Memory scales up as you add more users because of liveQuery caching, but CPU is way more dependent on your methods and what you are doing on the server side.

As I said on Crater, the big thing is that all publications and methods are blocking and will cause your backend node based Meteor server to only work on those requests instead of handing out HTML to new visitors. Turns out that is a bad user experience. I would never deployed to production with less than 2 app servers.