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 other requests at some point (see Amdahl's law). >
Yes, in case you're doing heavy database work you certainly want to have enough connections available to avoid contention. In our case, we had a couple of short database transactions wrapped around other computational work, including a call to an external service (we know). The thing we found counter-intuitive was that when the external call got slow (as they always do), we started being unable to checkout database connections. Not a particularly common or desirable use-case, I know, and I now get that we can work around this by manually checking out connections, so that part is good. I'm certainly not suggesting that optimising for the above case is a good idea; like I said, I was just interested. I don't really come from a web or Ruby background, I'm used to resource sharing systems either forcing you to explicitly checkout/checkin manually or automatically checkout/checkin when you request the resource. I guess threads in web are pretty short lived so it wouldn't normally be an issue. On Sunday, 27 September 2015 06:54:16 UTC+10, Aaron Patterson 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 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. -- 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.
