On Oct 10, 2013, at 9:11 PM, John Anderson <[email protected]> wrote:
> Hey, I was wondering if it would be possible to add some extra logging to the > QueuePool for when its using overflow connections vs a connection out of the > pool. I'd just use a "checkout" event handler and then log out pool.status() to get at this, it shows current overflow among other things. > > We currently are using a pool_size of 1 and a max overflow of 10. These were > just random settings set in a library and no one really noticed at first, those seem like awkward settings for a multithreaded app. > For our app design we have paster running 10 worker threads and we are using > the threadlocal strategy. The "threadlocal" thing isn't really something needed with modern usage patterns (is this create_engine() threadlocal or pool_threadlocal?), with the exception of using SQLite :memory: databases. Of course if you're using patterns that rely upon the threadlocal behavior then you'd need to address that. > Should we have a pool_size for the amount of worker threads we have so that > they each get their own? Seems reasonable... > > My understanding of how the QueuePool is working is it'll pull a connection > from the queue and it'll mark that connection with the thread that accessed > it so for our current setup of a pool_size of 1, we'll have a single worker > who gets the pooled connection and everyone else is going to get overflow > connections, right? pretty much > > So, in our specific case where we don't use transactions at all, it probably > makes most sense to remove threadlocal strategy and to increase our pool_size > to the amount of workers we have? yeah I don't think "threadlocal" is getting you anything here.
signature.asc
Description: Message signed with OpenPGP using GPGMail
