jemalloc may have helped reach your goals with the Ruby implementation. speedshop.co/2017/12/04/malloc-dou...
In theory, jemalloc would have been more conservative in post-boot allocations, keeping memory consumption growing at a lower rate and eventually more stable, due to its focus on handling fragmentation. It wouldn't do much to the baseline memory consumption that Puma/Sidekiq require after boot.
Is this a fair statement? I've never had the chance to try jemalloc myself, so I'm unaware of how it affects the runtime in practice. I've read a few articles here and there.
Sounds like a fair statement. Not sure what we can do about baseline memory requirements on boot.
Though I'm currently using jemalloc on a Standard 1x Heroku dyno (512MB ~ $25/mo) serving about 1.5 million requests/day and it averages 275MB of memory usage with a mean response time of 35ms.
Note that this is a standard Rails 5+ app using Sidekiq for background jobs. Currently processing about 50k jobs/day.
That's a very efficient Rails app, well done!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.