schneems
commented
1 year ago This project was an experiment that was aimed at helping people avoid swapping to disk on Heroku. Unfortunately getting an accurate memory value from within the container is basically impossible (for now, without some kind of special API or something). It was intended to be the smarter version of puma worker killer.
it turns out that simpler is better in this case (if we cannot be confident about the memory number). And puma worker killer meets most people’s needs.
To that end it’s not really in active development, but it’s also not quite dead either. If something were to change with containers then I might want to revisit this. If you’re interested in the project I can give you commit.
Hey there, is this still active?
This project was recently brought to my attention because it is being used by the TechEmpower benchmarks for Ruby to tune Puma in that portion of the benchmarks. That in turn made it difficult to directly support JRuby since puma_auto_tune primarily sets up workers, which are unsupported in JRuby.
So, if this project is still being maintained, maybe we could talk about what autotuning for JRuby would look like?
Memory is not going to vary substantially when adding more concurrent users; only what would be in-flight for each concurrent request would need to be considered, since all the rest of the runtime and framework are shared across threads. So there's only a small amount of memory change to be considered, with the bulk of the tuning related to number of available CPUs.