I think we're running about .5GB of RAM per instance on PUMA, so we have a WEB_CONCURRENCY of 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.
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)
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.
For further actions, you may consider blocking this person and/or reporting abuse
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?
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.
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.