I’ve had a successful deployment of my production app on Amazon EC2 using t2.small, but I’m wanting to upgrade the instance type to handle more traffic, more quickly. I was just curious if because Meteor is Node.js based, does that by default lean into more compute-optimized instances or memory-optimized instances? I know it comes down to your application but I’m curious if there’s a recommended preference just because the app is Node.js based. My specific app is not compute-bound (not processing anything on the server), it’s more database-driven with the app being centered around “data-views” and has a particular need for a really high number of simultaneous connections - like thousands all in brief periods of time. So I’m considering that more memory-bound but I’m not sure. Also Node.js is single threaded so would my app even take advantage of multiple CPUs on an instance? Or should I always be instancing single CPU machines? I host my database at compose.io so I’m not worried about the database (though I probably should look into that too).
i would opt for compute for sure, your app will run out of cpu before it runs out of memory
and no node doesnt use multiple cpus unless you use something like passenger to spawn multiple node processe. You can checkout my deployment script that does just that https://github.com/smowden/meteor-ansible
TL;DR: CPU is probably more important, but your mileage will vary depending on your app.
I have two meteor apps, one to handle a public front-end user interface and one to handle backend data analytics and management. These apps share the same Compose.io hosted database, but have entirely different footprints for CPU and RAM usage on the same EC2 instance type.
Surprisingly, or maybe not, the backend app takes up much more CPU and RAM than the front end app. Even though the front-end app has significantly more simultaneous usage.
I think the biggest factor here is the amount of data being sent around through pub/subs. At any time, the backend app is just working with a lot more data than the front end app is. Being judicious about using pub/subs has helped cut down its CPU usage significantly.
Hope that helps.
I would also recommend using Kadira to profile your app’s performance, before picking an instance type or when comparing instance types.
Thanks - helpful. I know it on your app too, but I curious if Node.js/Meteor historically played nicer on one or the other because of the way Node.js works.
Depends on how much you need to handle.
We use T2’s for smaller apps, C4 for large traffic apps. Running multiple instances of the app on different threads. Obviously, there is a huge price difference between those two.