Publishing flamebait [Fwd: Pragmatic Bookshelf releases "From Java To Ruby"]
lukfugl at gmail.com
Wed Jun 28 15:33:05 MDT 2006
On 6/28/06, Barry Roberts <blr at robertsr.us> wrote:
> How can you have a real enterprise-level web-based application
> framework in a language without real threads? Are all Ruby app
> servers on single-processor machines?
> I'm not trying to start a flame war, I really just want to know.
> Although, I suppose creating any kind of spark in the tinderbox that
> is plug could probably be considered flamebait, I am really interested
> in how rails is scalable without native threads.
Hmmm, as long as you're referring to web applications, I'll answer
your question. The lack of native threads in Ruby *has* been a
hindrance in other application domains; a situation that will
hopefully be remedied soon with the advent of the YARV virtual
But web applications? I've not run into any web application yet --
rails or perl or anything else -- that has needed multiple threads
*within* a request. So the only real need *I've* seen (I admit my
exposure may not be yours) for concurrent processing in a web
application environment is for handling multiple concurrent requests.
There are several ways to make multiple concurrent requests scale in
Ruby/Rails without native threads. You're right that Ruby's "green"
threads are *not* one of those ways. The most common approach that
I've seen is to simply switch from threads to processes. Multiple
processes (usually FastCGI or the newer Mongrel) are spawned,
listening on their own ports, or even on their own boxes. One or more
webservers (e.g. apache or lighttpd) can then proxy requests amongst
those many listening processes. Violá!
More information about the PLUG