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 > > / check out connections. > > > > I dunno, it feels to me like under normal circumstances you'd not see any > *more* lock contention. I would *guess* that under the current scheme, the > first few web transactions would be fast (no locking at all), but after > that you'd end up waiting on average about the same amount of time (since > each thread has to wait for a connection before it can get started
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). > and then > needs to do *all* its operations before it checks it back in). I'm curious, > I'll see if I can mock something up to test this using the existing > checkout/checkin functionality. Sounds good! :D -- Aaron Patterson http://tenderlovemaking.com/ -- 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
pgpmW4NXzwG9J.pgp
Description: PGP signature
