Thanks a lot Jeremy, We will see if by preconnect we are able to optimize things. Else we look into a non-blocking implementation of the connection pool ourselves. Regards Shashank
On Mon, Dec 25, 2017 at 8:50 PM, Jeremy Evans <[email protected]> wrote: > On Sunday, December 24, 2017 at 10:34:55 PM UTC-8, shashank Jain wrote: >> >> Also as you said issue might be with cruby due to global interpreter >> lock, but since we explicitly measured timings on acquire method on thread >> pool via rbtrace, looks like the thread is scheduled and then waits on some >> lock within the threadpool >> > > Yes, there is a Mutex+ConditionVariable that controls modifications to the > internal connection pool variables. With 300 concurrent threads all trying > to checkout a connection, even if there is not much code run while holding > the mutex, that could easily be a bottleneck. 300 threads is not a case > that CRuby optimizes well for in general, and not a case Sequel's > connection pool is optimized well for specifically. This is one of the > reasons that Sequel allows you to provide your own connection pool class. > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sequel-talk" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/sequel-talk/5NNUNaHqIMY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sequel-talk. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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 https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
