A couple of notes: Puma has a dynamic pool but it's common to see people configure the pool as 16:16 in production, meaning it's staticly configured to 16 threads.
Some people have asked about using Puma to manage multiple apps recently. I'm currently consider what that would look like. If it's done, it would likely be a separate gem rather than being wired directly into Puma as it is now.
On the topic of time limiting requests, this is conscience choice. Aborting a thread or process externally is really problematic and I don't personally think it's something that should be done casually. If a user wants to do time limiting, they can easily use a Rack middleware that uses timeout.rb.
The same goes for OobGC. Performing it in a multithreaded env makes little sense because the only out-of-band is when all threads are idle. I have thought of some ways to implement it in puma, but I see OobGC is a kludge. Better to tune your interpreter to handle your garbage load better (something 1.9/2.0/rubinius/jruby can all do).
Thanks for the great comparison! I look forward to future back and forth and we all work to raise the level of technology used in ruby webservers.
I keep reading how Puma is meant for be run multi-threaded on JRuby or Rubinius.
Would it be non-sense to run it in "cluster" mode (multi-process) under MRI 2.0? Similar to how we'd run Unicorn, for example. Any benefits doing that versus just running Unicorn?
EDIT: we have plenty of ram so that's not really a concern
Unicorn currently does have better fault-tolerance tools than Puma though, e.g. the 1-minute timeout on that Unicorn has by default. Unicorn also currently has more documentation than Puma. So there is a tradeoff in the choice, and there's still plenty that all the app servers can learn from each other.