Re: [Rails-core] ActiveRecord connection pool management

On Monday, 5 October 2015 14:37:56 UTC+11, Michael Vigilante wrote: > This is also an excellent point; I wasn't aware this was the case. It > certainly feels like a waste to be doing this every time a database > operation is run. I'm not sure what an appropriate level of alive-checking > is;

Re: [Rails-core] ActiveRecord connection pool management

On Friday, 2 October 2015 05:28:01 UTC+10, Matt jones wrote: > > > With per-DB-interaction checkin/checkout, it doesn't appear to be possible > to reliably manipulate these variables, as the connection used in the first > statement may not match the one used in the second. More amusing / >

Re: [Rails-core] ActiveRecord connection pool management

Agreed. The biggest benefit is going to come to people using a DB like Postgres where each connection uses an entire backend (forked worker essentially), and, given the high cost of backends, it's recommended to keep the number of connections low. Checking connections in/out of the pool as

Re: [Rails-core] ActiveRecord connection pool management

We run into problems with connection pools on Heroku. In Postgres a connection is very expensive. The cheap/free plans on Heroku Postgres all have very small connection limits. The hobby plan is limited to 20 connections https://devcenter.heroku.com/articles/heroku-postgres-plans. Some

Re: [Rails-core] ActiveRecord connection pool management

If the concern is long-running threads holding DB connections they don't need, wouldn't a simpler solution be to explicitly return connections to the pool (via release_connection) before doing a long-running non-DB operation? Checking out and back in on most operations seems like optimizing for

Re: [Rails-core] ActiveRecord connection pool management

On Thu, Oct 1, 2015 at 4:25 AM, Xavier Noria wrote: > The only time I've seen one connection per thread being an issue was in > one app that ran many processes and it started to reach the connection > limit of their db server in traffic peaks. Even in that scenario, >

Re: [Rails-core] ActiveRecord connection pool management

The only time I've seen one connection per thread being an issue was in one app that ran many processes and it started to reach the connection limit of their db server in traffic peaks. Even in that scenario, contention is also a risk if you reduce the pool. Other than the mental image that

Re: [Rails-core] ActiveRecord connection pool management

"it checks out a connection separately for each database action" Transactions are per connection, how does that approach handle them? -- 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

Re: [Rails-core] ActiveRecord connection pool management

Xavier, As far as I know, Rails already doesn't wrap the entire request in a transaction, so that shouldn't be an issue. Unless what you're saying is that operations already wrapped in a transaction block would be affected. On Wed, Sep 30, 2015 at 1:29 PM, Xavier Noria wrote:

Re: [Rails-core] ActiveRecord connection pool management

> > On Thursday, 1 October 2015 03:30:55 UTC+10, Xavier Noria wrote: > > Transactions are per connection, how does that approach handle them? > >From what I can tell, ActiveRecord only provides one way to manually open a transaction, which is a `transaction do ... end` block; in this case, if

Re: [Rails-core] ActiveRecord connection pool management

On Mon, Sep 28, 2015 at 10:01:23PM -0700, Michael Vigilante wrote: > OK, mock-up is here: > https://github.com/stranger-zedd/activerecord-connection-pool-tests Ah, I see what you're saying now. TBQH, as it really seems fine if we internally do check connections in. I just don't know how much

Re: [Rails-core] ActiveRecord connection pool management

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,

Re: [Rails-core] ActiveRecord connection pool management

On Sun, Sep 27, 2015 at 01:23:44AM -0700, Michael Vigilante wrote: > > Constantly checking out a connection then checking it back in seems like > > it would cause a performance bottleneck. The assumption is that lock > > contention will become the bottleneck if we have to constantly check in >

Re: [Rails-core] ActiveRecord connection pool management

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 >

Re: [Rails-core] ActiveRecord connection pool management

On Sunday, 27 September 2015 06:54:16 UTC+10, Aaron Patterson wrote: > Is it counter-intuitive? If you're doing database intensive work, then > you'd probably want the same number of connections as you have request > threads in order to maximize throughput, otherwise you'll still be > blocking

Re: [Rails-core] ActiveRecord connection pool management

On Thu, Sep 24, 2015 at 10:42:39PM -0700, Michael Vigilante wrote: > Hi, just a small question on the way connections are managed in > ActiveRecord. > > From the best I can gather reading the code (and based on behaviour), > ActiveRecord will check a connection out of the pool the first time a

[Rails-core] ActiveRecord connection pool management

Hi, just a small question on the way connections are managed in ActiveRecord. >From the best I can gather reading the code (and based on behaviour), ActiveRecord will check a connection out of the pool the first time a thread asks for one, then that thread will continue to hang on to the