OK, mock-up is here: https://github.com/stranger-zedd/activerecord-connection-pool-tests
On Tuesday, 29 September 2015 08:37:43 UTC+10, Michael Vigilante wrote: > > On Tuesday, 29 September 2015 00:46:14 UTC+10, Aaron Patterson wrote: >> >> I don't really follow. If you have 5 request threads, and 5 connections >> available, no request thread will contend on a lock for a connection >> (unless you are using threads, which means you'd have 1 + new >> threads.count >> connections used, which I said is off the beaten path). >> > > Sorry, I meant in the case where you have, say, a pool of five connections > and ten request threads (which is entirely possible given the default Rails > and, say Puma configuration). Where you have a thread per connection, I'd > expect the existing model to perform very slightly better because you only > have to go through the process of acquiring the connection once per thread > (rather than going through the locking/synchronising process multiple > times). I'd expect them to wait about the same time in this situation when > all (or at least a large majority) of the work being done by the app is in > the database; the more time you spend processing in the app, the more you > could benefit from releasing the connection between database work. > > Working on that test case right now, will get back to you :) > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
