I have noticed that Rails appears to open only one connection to the database. Say I have dozens of simultaneous requests. Will rails open additional connections to handle the load or will my application slow down due to competition over the database connection (because threads are blocked waiting for synchronized db connection)? Thanks, Rich
This has been discussed on the list before. While I''m no authority, it seems that the philosophy behind the lack of a connection pool is that since FCGI gives each web user a thread of their own, and since each thread has a connection to the database, there is no need to have connection pooling. I''m not sure if the same applies to CGI or mod_ruby. It doesn''t apply to Webrick. Duane Johnson (canadaduane) On May 27, 2005, at 12:37 PM, Rich Collins wrote:> I have noticed that Rails appears to open only one connection to > the database. Say I have dozens of simultaneous requests. Will > rails open additional connections to handle the load or will my > application slow down due to competition over the database > connection (because threads are blocked waiting for synchronized db > connection)? > > Thanks, > > Rich > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
In a production setting(fastcgi) each instance of rails will have it''s own connection to the database. A common setup is to have 5 fcgi listeners setup, so each of those would have it''s own connection to the database. Since the listener sticks around between requests, the database connection will stay connected as well. On May 27, 2005 12:37 pm, Rich Collins wrote:> I have noticed that Rails appears to open only one connection to the > database. Say I have dozens of simultaneous requests. Will rails open > additional connections to handle the load or will my application slow > down due to competition over the database connection (because threads > are blocked waiting for synchronized db connection)? > > Thanks, > > Rich > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-- Scott Brooks Network Operations Manager Binary Solutions Ltd. sbrooks-7+OF9GBfT4Xe9wHmmfpqLOTW4wlIGRCZ@public.gmane.org
I see. So using FCGI, requests are queued until an FCGI listener is available. Each listener has its own connection created when the listener is initialized. So if I want more connections (ability to handle load) I just need more listeners. Scott Brooks wrote:>In a production setting(fastcgi) each instance of rails will have it''s own >connection to the database. A common setup is to have 5 fcgi listeners >setup, so each of those would have it''s own connection to the database. >Since the listener sticks around between requests, the database connection >will stay connected as well. > >On May 27, 2005 12:37 pm, Rich Collins wrote: > > >>I have noticed that Rails appears to open only one connection to the >>database. Say I have dozens of simultaneous requests. Will rails open >>additional connections to handle the load or will my application slow >>down due to competition over the database connection (because threads >>are blocked waiting for synchronized db connection)? >> >>Thanks, >> >>Rich >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > >
Exactly. So you basically have a "pool" of rails instances handling the incoming requests. Each holds its own dedicated connection to the database. To cope with more traffic you can increase this pool of instances. This is not restricted to a single server, you can have multiple server running instances of your application. A good fastcgi implementation can distribute requests to servers on low load. On 5/27/05, Rich Collins <rcolli2-odAbcf0Mc9JJm/Hvfsr4+Q@public.gmane.org> wrote:> I see. So using FCGI, requests are queued until an FCGI listener is > available. Each listener has its own connection created when the > listener is initialized. So if I want more connections (ability to > handle load) I just need more listeners. >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
So how many instances does a site like Basecamp utilize? On 5/27/05, Tobias Lutke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Exactly. So you basically have a "pool" of rails instances handling > the incoming requests. Each holds its own dedicated connection to the > database. > To cope with more traffic you can increase this pool of instances. > This is not restricted to a single server, you can have multiple > server running instances of your application. A good fastcgi > implementation can distribute requests to servers on low load. > > On 5/27/05, Rich Collins <rcolli2-odAbcf0Mc9JJm/Hvfsr4+Q@public.gmane.org> wrote: > > I see. So using FCGI, requests are queued until an FCGI listener is > > available. Each listener has its own connection created when the > > listener is initialized. So if I want more connections (ability to > > handle load) I just need more listeners. > > > > -- > Tobi > http://www.snowdevil.ca - Snowboards that don''t suck > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Duane Johnson wrote: > Rich Collins wrote: > >> I have noticed that Rails appears to open only one connection to the >> database. Say I have dozens of simultaneous requests. Will rails >> open additional connections to handle the load or will my application >> slow down due to competition over the database connection (because >> threads are blocked waiting for synchronized db connection)?> This has been discussed on the list before. While I''m no authority, it > seems that the philosophy behind the lack of a connection pool is that > since FCGI gives each web user a thread of their own, and since each > thread has a connection to the database, there is no need to have > connection pooling. > > I''m not sure if the same applies to CGI or mod_ruby. It doesn''t apply > to Webrick.From "Agile Web Development With Rails" (beta): "...WEBrick is a great way of getting up and running quickly, but not a particularly attractive approach for heavy-duty use. One of the reasons is the lack of thread-safety in Action Pack, which forces WEBrick to place a mutex at the gate of dynamic requests and only let one request through at the time." So even though WEBrick is multithreaded, it looks as if Rails on WEBrick couldn''t benefit from multiple database connections. The same would apply to mod_ruby. I don''t see how CGI could do anything else but open a connection for each request. FCGI actually uses separate processes, rather than threads, so uses a DB connection per process. Justin