Ah, good point. Yeah, in theory, I think that's true, you could get away with only one worker on rubinius or jruby.
I'm mostly sticking with MRI, so I mostly think about the other side -- on MRI you need multiple workers, yeah, but _even_ on MRI, you get a boost by using multi-threads _on each worker_. This is the thing lots of people are neglecting!
Although to the extent that there may be some shared resources between threads, which may be shared under an architecture where the more threads you have contending for resources, there is a performance penalty....
...you _may_ seen performance improvements by having more than one worker even on jruby or rbx, without the GIL.
It would really have to be benchmarked, with some apps with realistic profiles.
But yeah, I'd expect the advantage of having more than one worker on rbx or jruby to be less. But it gets confusing.
(The ActiveRecord database connection pool is the prime example of such a shared-under-contention resource)
You get a big boost by using multiple Puma workers on MRI. Under Rubinius you should be able to only use one Puma worker for max performance, right?
I'd love to see benchmarks with Rubinius... ;)