On 9/7/07, Erik Hetzner <[EMAIL PROTECTED]> wrote: > processes. True, on a multiprocessor machine Ruby isn't going to take > advantage of the situation without native threads or running multiple > processes. But it may turn out that a mixture of multiple processes > AND green threads provides greater performance than plain old multiple > processes.
I can state with a great deal of confidence that in this problem domain, Ruby's green threading will not get you greater throughput. A given process can only do so much work. If, in the course of doing that work, there is an external latency, such as waiting on some IO, that can be done in a non-blocking way, then it's possible to get more work out of that process per unit time by using threads. The work involved in handling web browser requests and rendering responses back to them, though, doesn't tend to fall into this category. It tends to be CPU intensive, and when one is waiting for something external, like a database query, one is usually waiting inside the body of the low level extension based database driver, so thread context switching doesn't happen there, anyway. The most efficient way of dealing with these sorts of things, from a throughput perspective, is to avoid the overhead of threads completely and just pound them through, one at a time, with 100% of the process resources working on that single request at a time. This doesn't change if you have one process or ten processes for your app/site. Kirk Haines swiftiply.swiftcore.org analogger.swiftcore.org _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
