It's been great to hear about how you're managing servers, backups, etc. for Forem.dev. I've yet to go beyond using Heroku.
One of the posts here mentioned that Dev.to is still running on Heroku. Just so we get a sense of Forem's scale (I'm referring to the open-source project and not this web site), would anyone on the team be able to share what type of solution Dev.to is currently using for its systems (for example, how many dynos, Postgres RAM/storage, etc.).
Obviously Dev.to is a particularly large community and maybe not very representative but it would be interesting to get some context for the scale of resources used to run a Forem-based community.
Top comments (6)
I think we're running about .5GB of RAM per instance on PUMA, so we have a
WEB_CONCURRENCYof 16 right now and averaging 7-8 GB of Dyno load. I imagine this is the most "day 1"-intensive metric. We have a big ole database, but I imagine we could go smaller and of course other communities could too.@jdoss , @molly_struve want to weigh in?
Do you have to do anything special on Heroku to get this to work for smaller instances scaled out? We've run into memory issues with anything less than Performance M dynos (2.5 gb per instance). So right now we are running a single 2.5gb instance.
Our usage is also pretty light, maybe 20 concurrent users at a time (usually 2-3)
YES!!! We cut our memory usage in half by switching to jemalloc. You can read about it on dev.to 👉 dev.to/devteam/how-we-decreased-ou...
Thanks for sharing this, we will give it a try tonight. We are also using fastly, which is why I was shocked at the base memory requirements for the application.
Also important to keep in mind that dev.to is heavily using Fastly for edge caching so many of our hits never even have to hit our servers.
This article might help. :)