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 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.
