Hello all. Bear with me, there is a Mongrel question in here ;) I have been having some fun with database connections and ruby. Long story ( Found here: http://www.ruby-forum.com/topic/56047 ) short: I was making far too many in my application. I eventually fixed this (I thought) and when running webrick there were only ever two connections (One to each database) no matter how many users, this was perfect! so I thought "Great! I''ll now put it on that mongrel server I have read so much about since it kicks the stuffing out of webrick and is perfectly suited to a smallish intranet site!". Having messed around (Read: failed) with Apache getting Mongrel running was so simple (Thanks!). Then after a bit of testing I got shouted at by the Service department for a steadily increasing number of connections to the Oracle server. Having read up on Mongrel I see there is an option to limit the number of threads it can use. My question is: Does each thread correspond to a "Running" instance of the application? If so then limiting that would theoretically limit the number of DB connections...right? When I look at the task manager (Yet, I am running windows...no I didn''t have a choice in the matter ;) I see only once instance of ruby.exe running. The threadedness of mongrel is the only difference I can see between it and the (I assume) threadless and working Webrick Thanks for reading through this rambling tale of adversity, sorrow and great dogs and I am hoping you can give me a happy ending. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060228/bc1736f6/attachment.htm
Maybe Zed could answer this better, but will to a shot ;-) Comments bellow... On 2/28/06, Jeff Jones <jjones at raindrop.co.uk> wrote:> > > > Hello all. > > Bear with me, there is a Mongrel question in here ;) > > [snip] > > Having messed around (Read: failed) with Apache getting Mongrel running was > so simple (Thanks!). Then after a bit of testing I got shouted at by the > Service department for a steadily increasing number of connections to the > Oracle server. > > Having read up on Mongrel I see there is an option to limit the number of > threads it can use. My question is: Does each thread correspond to a > "Running" instance of the application? If so then limiting that would > theoretically limit the number of DB connections...right? When I look at the > task manager (Yet, I am running windows...no I didn''t have a choice in the > matter ;) I see only once instance of ruby.exe running. >The Threads that mongrel uses are only for socket connections. These "workers" only perform the socket handshake and leave the reply stuff to the CGI Wrapper (which in this case is rails). If you check the code in mongrel_rails, you will see that because rails isn''t "thread-safe", a Mutex was used to avoid controllers from executing simultaneously. The number of active connections shouldn''t be different from webrick. I don''t know if there is a way to dump information from active or opened connections, maybe using script/console? I guess don''t have a lot of experience debugging code :-P -- Luis
Hi Luis Thank you for the reply. It does shed some light on things.> If you check the code in mongrel_rails, you will see that because > rails isn''t "thread-safe", a Mutex was used to avoid controllers from > executing simultaneously. The number of active connections shouldn''t > be different from webrick.I have run the server with the -n 1 Parameter for a while now and it only uses two connections (as it should). Because of this I am drawing the following conclusion. 1. (Most likely) My code is somehow buggering up ( I am a beginner after all). 2. Rails is somehow thinking that there is no DB connection when run from a second thread due to a rails bug. 2. Rails is somehow thinking that there is no DB connection when run from a second thread due to the way the MUTEX is coded. (I haven''t looked at the source code, being a beginner it probably wouldn''t help) I will see if I can find out more but this is a personal project so I can only do it at lunchtime. Jeff
Hi Jeff, You''ve pretty much figured it out, but there''s a bit more detail. First, here''s how AR does "thread safety". AR creates DB connections and then puts them in the thread local storage. What this means is if you run any app with AR then you get one DB connection per thread you use AR in. Now, what mongrel does (which is shown by the -n option) is it creates a small set of work threads to process requests. Initially this is 20. What you should see is as AR gets used your connections will increase up to 20. The reason is each worker thread will get it''s only copy of the thread local DB connection from AR. With your setting to -n 1 you can keep the DB connections down to 2, but then you don''t get any advantage of parallel processing. So, you''ve got two choices: 1) Use a -n parameter that''s reasonable for your uses but doesn''t kill your performance. If you need to only ever have 2 then do #2. 2) Add ActiveRecord.threaded_connections = false to your environment.rb What #2 does is tells AR to make one connection and always use that. I may just add an option to mongrel_rails that sets this for you since people keep asking about it. Zed On Wed, Mar 01, 2006 at 04:34:54PM -0000, Jeff Jones wrote:> I have run the server with the -n 1 Parameter for a while now and it only uses two > connections (as it should). Because of this I am drawing the following conclusion. > > 1. (Most likely) My code is somehow buggering up ( I am a beginner after all). > 2. Rails is somehow thinking that there is no DB connection when run from a second thread due to a rails bug. > 2. Rails is somehow thinking that there is no DB connection when run from a second thread due to the way the MUTEX is coded. (I haven''t looked at the source code, being a beginner it probably wouldn''t help) > > I will see if I can find out more but this is a personal project so I can only do it at lunchtime. > > Jeff > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
zedshaw at zedshaw.com wrote:> 2) Add ActiveRecord.threaded_connections = false to your environment.rb > > What #2 does is tells AR to make one connection and always use that. > > I may just add an option to mongrel_rails that sets this for you since > people keep asking about it.There''s a thread on rails-core about this now, and in the ticket referenced below. That config is now called "allow_concurrency" (set to false), and is supposed to be set in environment.rb. http://dev.rubyonrails.org/ticket/3979
Hi Michael and Zed. Thank you for all the help. I actually read that thread a few days ago but the significance of it didn''t dawn on me. I will try the allow_concurrency change and see if there is an obvious performance difference. Thanks for the help. Jeff -----Original Message----- From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Michael Schoen Sent: 01 March 2006 20:41 To: mongrel-users at rubyforge.org Subject: Re: [Mongrel] Threading & database connections. zedshaw at zedshaw.com wrote:> 2) Add ActiveRecord.threaded_connections = false to your > environment.rb > > What #2 does is tells AR to make one connection and always use that. > > I may just add an option to mongrel_rails that sets this for you since> people keep asking about it.There''s a thread on rails-core about this now, and in the ticket referenced below. That config is now called "allow_concurrency" (set to false), and is supposed to be set in environment.rb. http://dev.rubyonrails.org/ticket/3979 _______________________________________________ Mongrel-users mailing list Mongrel-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
Jeff Jones wrote:> Thank you for all the help. I actually read that thread a few days ago > but the significance of it didn''t dawn on me. I will try the > allow_concurrency change and see if there is an obvious performance > difference.Edge has now been patched to solve this, and allow_currency false is now the default.