# A small doublt

**URL:** <https://www.ruby-forum.com/t/a-small-doublt/150220>\
**Category:** Rails\
**Created:** [October 6, 2008, 8:21am UTC](https://www.ruby-forum.com/t/a-small-doublt/150220 "2008-10-06T08:21:03Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 6, 2008, 8:21am UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/1 "2008-10-06T08:21:03Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 6:32pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/2 "2008-10-08T18:32:49Z")

</div>

> 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 D. wrote:

> 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 ?

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 7:23pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/3 "2008-10-08T19:23:32Z")

</div>

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/](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.

On Oct 8, 9:32 am, Robert W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 8:16pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/4 "2008-10-08T20:16:28Z")

</div>

On 8 Oct 2008, at 17:32, Robert W. \<rails-mailing-list@andreas-  
[s.net](http://s.net)\> wrote:

> > 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

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 8:52pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/5 "2008-10-08T20:52:11Z")

</div>

> 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 C. wrote:

> On 8 Oct 2008, at 18:22, Michael S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> >

…snip…

> Fred

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 8:13pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/6 "2008-10-08T20:13:32Z")

</div>

On 8 Oct 2008, at 18:22, Michael S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.  
> 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

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 13, 2008, 6:33am UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/7 "2008-10-13T06:33:33Z")

</div>

Thanks for all your reply  
now i understand.

---

<div class="post-metadata">

**Author:** ![mokkai](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c2a13f/32.png) [@mokkai](https://www.ruby-forum.com/u/mokkai)\
**Post date:** [October 8, 2008, 8:58pm UTC](https://www.ruby-forum.com/t/a-small-doublt/150220/8 "2008-10-08T20:58:10Z")

</div>

On 8 Oct 2008, at 19:52, Robert W. wrote:

> > 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
