i don't understand that request ... response process in rails framework .
is a single thread(ruby green thread) created for everyone request? then that single thread will be living upto the response send. am i correct ?
is a single thread(ruby green thread) created for everyone request?
I'm going to go out on a limb here since no others have responded, but my understanding (at least in the current version of Rails) is no. I don't believe than a thread is created at all. It is my understanding that the Rails application instance is a single processes thread that handles the request all the way through to the response. The Rails application instance will block from the time it receives a request to the time it completes the response.
To handle requests concurrently you need to have multiple Rails processes running. Typically you would use a Mongrel cluster for this. For best performance you also need a load balancer that is smart enough to know not to send a request to a busy Rails instance, otherwise, that request will be blocked until the Rails process completes it's current request.
However, my understanding is the Mongrel, or Thin or whatever is concurrent and will queue up the request that it sends to the Rails instance for processing.
That being said this is not that unusual. I believe that PHP applications would work in a similar way. They would spin up a process to handles each request. One process handling one request.
This is actually a safe and scalable solution. Threading is HARD! And, it's dangerous if not done correctly. And in the end it doesn't really help you scale as much as you might expect.
I'll reiterate that this is my own understanding of this, and I could be completely off-base.
Pokkai Dokkai wrote:
Yes, mongrel_cluster is the way to go if you want to handle multiple concurrent requests. I recommend nginx over Apache for load balancing them, if you have the choice.
Threading is indeed hard, but it helps immensely with scaling problems. That being said, Ruby threading is not very good at all and ActiveRecord is not threadsafe, so Rails won't be threaded any time soon.
Check out Joe Domato's blog for an example of how poorly implemented and debugged Ruby threading is: http://timetobleed.com/ruby-threading-bugfix-small-fix-goes-a-long-way/
Robert is right about how Rails handles concurrent requests (many instances of application) and correct that Mongrel doesn't spawn Ruby green threads (a good thing if you looked at the blog post above). However, most other web frameworks I know of don't do it that way. PHP and J2EE will have a master process that spawns child threads to handle requests, as does nginx. This lets the OS handle load balancing, and switch out threads that are blocked (usually waiting for DB calls to return).
It would be better if Rails could do that but it can't. It's not a huge deal, unless you are running a very high-traffic site; just put up a Mongrel cluster and you will be fine.
Yes, mongrel_cluster is the way to go if you want to handle multiple concurrent requests. I recommend nginx over Apache for load balancing them, if you have the choice.
Threading is indeed hard, but it helps immensely with scaling problems. That being said, Ruby threading is not very good at all and ActiveRecord is not threadsafe, so Rails won't be threaded any time soon.
Actually rails 2.2 will be threaded (rc out real soon now).
Activerecord itself can be used in a threadsafe way (but not in a
rails app; i've got a few multithreaded daemons using active record).
Of course to see the most benefit you'll need a ruby implementation
with native threads, like jruby.
Fred
is a single thread(ruby green thread) created for everyone request?
I'm going to go out on a limb here since no others have responded, but my understanding (at least in the current version of Rails) is no. I don't believe than a thread is created at all. It is my understanding that the Rails application instance is a single processes thread that
It probably depends on what hosts rails. For example mongrel is most
definitely multithreaded and can handle multiple concurrent requests,
just not concurrent requests handled by rails.
Fred
Of course to see the most benefit you'll need a ruby implementation with native threads, like jruby.
Or Ruby 1.9 YARV if I'm not mistaken?
Frederick Cheung wrote:
...snip...
Of course to see the most benefit you'll need a ruby implementation with native threads, like jruby.
Or Ruby 1.9 YARV if I'm not mistaken?
IIRC ruby 1.9 is a bit special - threads are mapped to native threads,
but there's some giant mutex (IIRC to help compatibility with C-
extensions that could previously assume that everything was single
threaded from a native thread point of view) that limits the
effectiveness of this.
Fred
Thanks for all your reply now i understand.