Having access to the hash allows to produce stats in other ways (such as StatsD) without having to parse JSON of data that is available in memory. An example of this workaround is fa6ba1f507/lib/puma/plugin/statsd.rb (L112-L114)
Reduces runtime allocation by freezing string literals by default.
We could also remove a ton of manual `.freeze` calls, however the ruby supported version is 2.2 and the magic comment only targets 2.3+.
Currently we don’t know the max bound of the `pool_capacity` metric. We know `spawned` which is confusingly under the “running” keyword, however we don’t know if spawned is the highest it will possibly be.
By adding `max_threads` we know the upper bound for `running` threads and therefore the upper bound for pool capacity.
It should be noted that it’s not always guaranteed that puma will always create up to `max_threads`, a separate relationship between `running` and `max_threads` should be monitored as well (if min threads != max threads).
This PR introduces the `pool_capacity` stat which can be used as a “negative back pressure metric”.
What does a “negative backpressure metric” mean? It means when this number is low, we have a higher amount of backpressure. When it is zero it means that our worker has no ability to process additional requests. This information could be used to scale out by adding additional servers. When that happens the requests should be re-distributed between the extra server and the “pool capacity” number for each individual server should go up.
Daemonizing on JRuby returned an error status to the
invoking environment due to exit! defaulting to a
return status of „false“ in constrast to exit which
defaults to „true“.
