MIN_THREADS > 0 ?

[jurriaanschrofer]

I am very thankful for this wonderful gem, thank you all!

Secondly, I am most definitely at the wrong place here (sorry). I have been extensively browsing the documentation, googling online and doing some research – but I have a question about Puma that continues to bug me and I don't know where else to ask this question. If there is an appropriate place for this (instead of making a GH issue), please tell me.

Puma comes with some default settings for threads: 0 as min_threads and something like 8 or 16 as max_threads per worker / process. While I fully understand the dangers of raising the max_threads inconsiderately (unfortunately I am now dealing with production problems because of this), I can't wrap my head around the purpose of the min_threads: since a puma worker will create a thread for any web request when needed, why would you have to set any minimum value higher than 0?

Since most of the overhead takes places, as I understand, in the forking of workers / processes (due to every worker running its own application) but not in the threading within a process (merely costs some CPU but barely RAM), I can't grasp why you wouldn't just always create a thread on demand instead and keep the min_threads set to 0.

But I suppose there must be reason, for why else this would be a setting available in puma's interface?

[dentarg]

Since most of the overhead takes places, as I understand, in the forking of workers / processes (due to every worker running its own application) but not in the threading within a process (merely costs some CPU but barely RAM), I can't grasp why you wouldn't just always create a thread on demand instead and keep the min_threads set to 0.

For a busy app, spending "some CPU" might matter when it comes to handling requests quickly.

See also https://en.wikipedia.org/wiki/Thread_pool

[jurriaanschrofer]

@dentarg Thank you a lot for all the references, each of the readings were very insightful!

As I understand, modelling the right amount of puma processes, min_threads and max_threads is not something you do with a generic one-size-fits-all approach, but requires custom analysis of the application, its underlying hardware and its throughput (except perhaps the amount of workers, which you may always set equal to the amount of physical cores available on the server). Since we are recurringly running into production problems, I do want to do this analysis, but tbh are still not sure how to best do this... would you recommend using an APM such as New Relic or Datadog for this? I am aware this is no longer in scope of the original question (my pardon), but any little advice would be much appreciated.

Thanks a lot for the references and have a good day

[dentarg]

Really hard to say what you should do without knowing with kind of problems you are having. Having monitoring is of course almost always a good thing

I think your first question was fine for the puma issue tracker but now we are getting off topic. There's probably more suitable forums available (Stack Overflow perhaps?) (Feel free to link your post here if you create one when you close this issue)

[jurriaanschrofer]

Of course, thank you for the help. If any would be willing to look at my StackOverflow question, that would be very much appreciated!

https://stackoverflow.com/q/73635429/15048016