"the point of reverse proxying is not performance, it's security."
Not true. You absolutely need forking/multiple processes on rails deployments to enable even a small number of concurrent requests. If phusion wasn't forking and load balancing between those running instances, your performance would be far lower.
EDIT: See this article from the Passenger folks on tuning a passenger deployment, it should be more clear after reading that how Passenger is dealing with concurrency (by running multiple app instances and load balancing between them): http://blog.phusion.nl/2013/03/12/tuning-phusion-passengers-...
The concurrency tuning explained in that article has got nothing to do with reverse proxying. You don't need multiple processes either: the article says that you can use multithreading, and especially in the case of I/O-bound apps, that's enough. If you want to leverage multiple CPU cores however, that's a different story, but it depends on your Ruby implementation. If you use JRuby or Rubinius then threads are enough. But that is still unrelated to the question of whether to reverse proxy or not.
Not true. You absolutely need forking/multiple processes on rails deployments to enable even a small number of concurrent requests. If phusion wasn't forking and load balancing between those running instances, your performance would be far lower.
EDIT: See this article from the Passenger folks on tuning a passenger deployment, it should be more clear after reading that how Passenger is dealing with concurrency (by running multiple app instances and load balancing between them): http://blog.phusion.nl/2013/03/12/tuning-phusion-passengers-...