Can you provide any more details on your stack and what you're seeing that blows away alternatives?
I'm running a staging version of our Rails 3.8 app with MRI 2.1 and Puma in clustered/threaded mode and everything looks pretty good .. but I haven't been able to throw a ton of concurrent traffic at it yet. Potential thread safety issues give me the niggles, not quite ready to replace Unicorn on production just yet.
> Can you provide any more details on your stack and what you're seeing that blows away alternatives?
The really big thing is how just one puma worker with 8-16 threads can actually replace a set of about 6-8 unicorn/passenger worker instances and give you about the same level of performance.
That level of memory savings lets you use smaller boxes or put more puma workers on one box and eliminate others. Admittedly I'm not doing twitter request/minute numbers but I still was very pleased with my findings.
Theoretically, the number of puma threads you're running should be the same as the number of unicorn processes. That is, equal to the number of available CPU cores on the machine. So, if you're running on a machine with 8 cores, you should run 8 process or threads.
What continues to be the major issue with anything thread-based in ruby is that to reliably reach desired performance at load in a threaded setup, you need to be running an interpreter than can make concurrent use of native system threads. MRI has a global interpreter lock, so two pieces of ruby code will not run at the same time. IO is not subject to the GIL, so a lot of what happens in a web app can run concurrently (DB calls, etc), but other things that all happen in ruby (routing, view rendering) cannot.
So, basically, to reliably achieve similar performance using threads, you need to be using Rubinius or JRuby, which don't have a GIL.
