Hi I have some questions regarding threads in Mongrel and Rails. According to the FAQ: "Ruby on Rails is not thread safe so there is a synchronized block around the calls to Dispatcher.dispatch. This means that everything is threaded right before and right after Rails runs. While Rails is running there is only one controller in operation at a time." Isn''t this going to be a MAJOR bottleneck for most Rails apps? Or am I missing something? As I understand it a request comes is and gets routed to a controller which talks to the database (which takes up most of the time of the request) and no other request will be processed by rails until the database query is done and the result rendered and sent back to Mongrel? If this is the case, is there any work being done on making Rails threadsafe? I have tried to look for any info on this but haven''t found any. / Jonas
Hi Jonas, Yes, this is a MAJOR bottleneck, but it isn''t entirely all Rails'' fault. A lot of it has to do with how the Ruby interpreter does not thread protect it''s own dynamic class loading or quite a bit of the eval stuff that Rails uses. The other part is that Rails was developed mostly assuming that it''s running like a CGI, so threads just weren''t an issue there. This bites people in a couple of ways such as opening files and not closing them, spawning external programs and not waiting for them, opening sockets and not closing them, etc. It also makes Rails slower than it needs to be since there has to be this giant sync lock around the world. I have had a proposal or two to investigate various forking methods to improve things, but most of my experiments haven''t been too useful. The best options seems to just create a bunch of Rails processors and then have a fronting web server or load balancer farm out the requests. Thankfully Mongrel makes this pretty easy to do and it''s a standard best practice with any of the dynamic languages out there. Hope that helps explain the situation. Zed On 3/28/06 10:30 AM, "Jonas Tehler" <jegt at titanian.se> wrote:> > Hi > > I have some questions regarding threads in Mongrel and Rails. > > According to the FAQ: > > "Ruby on Rails is not thread safe so there is a synchronized block > around the calls to Dispatcher.dispatch. This means that everything > is threaded right before and right after Rails runs. While Rails is > running there is only one controller in operation at a time." > > Isn''t this going to be a MAJOR bottleneck for most Rails apps? Or > am I missing something? > > As I understand it a request comes is and gets routed to a controller > which talks to the database (which takes up most of the time of the > request) and no other request will be processed by rails until the > database query is done and the result rendered and sent back to Mongrel? > > If this is the case, is there any work being done on making Rails > threadsafe? I have tried to look for any info on this but haven''t > found any. > > / Jonas > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
Hi OK. So the talk about making YARV threadsafe will make the situation better? / Jonas On 28 mar 2006, at 18.06, Zed Shaw wrote:> Hi Jonas, > > Yes, this is a MAJOR bottleneck, but it isn''t entirely all Rails'' > fault. A > lot of it has to do with how the Ruby interpreter does not thread > protect > it''s own dynamic class loading or quite a bit of the eval stuff > that Rails > uses. The other part is that Rails was developed mostly assuming > that it''s > running like a CGI, so threads just weren''t an issue there. > > This bites people in a couple of ways such as opening files and not > closing > them, spawning external programs and not waiting for them, opening > sockets > and not closing them, etc. It also makes Rails slower than it > needs to be > since there has to be this giant sync lock around the world. > > I have had a proposal or two to investigate various forking methods to > improve things, but most of my experiments haven''t been too > useful. The > best options seems to just create a bunch of Rails processors and > then have > a fronting web server or load balancer farm out the requests. > Thankfully > Mongrel makes this pretty easy to do and it''s a standard best > practice with > any of the dynamic languages out there. > > Hope that helps explain the situation. > > Zed > > > On 3/28/06 10:30 AM, "Jonas Tehler" <jegt at titanian.se> wrote: > >> >> Hi >> >> I have some questions regarding threads in Mongrel and Rails. >> >> According to the FAQ: >> >> "Ruby on Rails is not thread safe so there is a synchronized block >> around the calls to Dispatcher.dispatch. This means that everything >> is threaded right before and right after Rails runs. While Rails is >> running there is only one controller in operation at a time." >> >> Isn''t this going to be a MAJOR bottleneck for most Rails apps? Or >> am I missing something? >> >> As I understand it a request comes is and gets routed to a controller >> which talks to the database (which takes up most of the time of the >> request) and no other request will be processed by rails until the >> database query is done and the result rendered and sent back to >> Mongrel? >> >> If this is the case, is there any work being done on making Rails >> threadsafe? I have tried to look for any info on this but haven''t >> found any. >> >> / Jonas >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >