I’ve been running my site for a while now and for the first year I had it running on a single $10/month DigitalOcean droplet while using Compose.io for the database.
Recently I had to scale up to multiple instances and now have 5+ $10/month droplets running on DO.
(The $10 DO instances have 1GB RAM and the $5 instances have 512MB RAM.)
The reason I went for the $10 instances was because I heard there were problems running Meteor apps with only 512MB RAM (I think it was Telecope that reportedly had problems running on 512MB RAM). But this seems to be only be a problem when using the Spiderable package, and I can use something like https://prerender.io/ for free instead.
In general, RAM isn’t the bottleneck in Meteor apps, CPU is. And I don’t get more CPU with a $10 DO droplet.
Based on all this, would it make sense for me to switch all my droplets from $10/month to $5/month droplets? And does it make sense in general to only use $5 droplets for Meteor projects when hosting on DO?
Did you try running it on the cheaper version? I mean you can just measure yourself how things work out for your application? It will be different per application.
I haven’t tried yet. I thought I’d post first. I don’t want my production
app going down due to heavy load when I’m testing it. And it’s a little bit
of work moving away from spiderable.
I’m hopefully launching an app in a couple of months so it’d be good to know a bit more about this. If you could post your findings as you go, that would be great!
I have had four separate apps running concurrently on a single $10 DO server.
Nginx in front of it all handled the different apps & URLs.
That being said, I never had any major load on any of them.
I have a very small production app running on a 1GB ($10/month) Droplet. I also have a “staging server” running on the 512MB ($5/month) Droplet.
The first runs great so far.
The second doesn’t get much heavy use at all so I wasn’t concerned. I heard similar things about Meteor and memory and figured the extra $5/month wasn’t worth quibbling over.
As additional detail, I’m currently running Mongo on the same instance as the app. This is likely to change and I will move the DB over to Compose.io. I’ve tested this with my staging server with very pleasing results. This change may reduce both CPU and memory needs on the main app server. But I haven’t confirmed that yet.
Bottom line: I probably wouldn’t penny pinch on the $5/month.
The problem with the 512 mb is probably about google fetching from search engine. So you probably need some swap. That’s what I encounter with DO 512. If you need more CPU power, it’s better to use multiple 512 or linode 2GB up. Linode’s CPUs are nice!
I have instances on my app running on all droplet sizes. From $5 to $20/month. The database is never hosted on the droplets. So far I’ve only used $10+ droplets for production, but seems it makes sense to switch them all out for $5 droplets instead. And using swap will solve the problems of accidentally going over the 512MB RAM limit which doesn’t seem to happen too much anyway. The most RAM I’ve seen my apps use is around 600MB according to Kadira. And the truth is that at that point, CPU is going to be an issue anyway. RAM usage seems to be 300-400MB most of the time.
I don’t know a lot about Phusion Passenger, but this seems to be the least cost effective solution. CPU is usually the bottleneck for Meteor apps. Both the $20 and $40 droplets only give you 2 CPUs. I could run 4 * $10 instances for 4 CPUs, or even better 8 * $5 instances for a 8 CPUs. Am I missing something?
Both the $20 and $40 droplets only give you 2 CPUs.
You can very easily run 4, even 8 or more meteor instances on a 2 cpu
server as long as your apps do not do things like long running image
processing, long calculations etc.
The #ofcpu=max#ofinstances is a very very old rule that’s only valid
for very old cpu architectures and cpu intensive blocking type single
threads.
I’m running five meteor apps, a mongodb server, three wordpress sites
and a static site all on a single $20 DO server for a client. The
meteor apps are each configured to start one instance and dynamically
increase on demand up to 4 depending on load. CPU is stable around 10%
with occasional spikes and RAM is around 1.2GB. I use prerender.io for
search engines.
That’s right, but what you then do would be to mix and match both
approaches to increase server density.
Also there’s almost always lots you can do to decrease cpu usage by
optimizing your publications or separate cpu intensive parts of your app to
a microservise on a dedicated server and consolidate the rest into one or
two larger servers.
The company I work for is about to launch, and we’ve been asking these same sort of questions.
We have a single deployed AWS instance at the moment, but of course, its not live to the public.
Database and app hosted on it.
I guess we’ll just have to add the package and see how it goes.
Does anyone else have experience with @arunoda 's cluster package, or am I reading this whole thread incorrectly?
The cluster package looks great. I don’t recommend using its multicore
functionality for now however. When I used it, during times of heavy load
the app would shut down and wouldn’t restart automatically. There’s an open
issue about this on Github. I’m not the only one that ran into this issue
either.
With regards to running cluster without using multicore support it seems
like a good option though. In the end I went with nginx for load balancing
which was easy since I was already using it for ssl. Cluster was my first
choice but I was limited for time and couldn’t figure out how to set it up
correctly across multiple servers.