I wonder if the issue is gone as well. After the db_pool code was removed, I was doing some separate testing of sqlalchemy's with_lockmode().. and I was able to reproduce a traceback from sqlalchemy that looked extremely similar or identical to the traceback we were hitting when using eventlet's db_pool. This was many months ago. I moved on to other things and I didn't keep any notes on what I was doing. A couple months ago.. I decided I should go look at it again. And I could no longer reproduce the issue... doing what I believe was the same test I was doing initially.
So... I wasn't testing db_pool, however I thought I was seeing the same traceback. And then I couldn't reproduce it anymore. So, I wonder if these were the same issue... and that the issue is gone now. I say it's worth trying the db_pool code again... but I'd make it an option so that we can enable/disable it. - Chris On Mar 6, 2012, at 9:39 AM, Yuriy Taraday wrote: > Now I had no luck trying to reproduce problem that appeared with > db_pool. Maybe it's gone? > Who can walk me through the way to that bug? I think, we should fix it > if it's not fixed already, bring back db_pool and then eventlet will > be all good again, am I right? > > Kind regards, Yuriy. > > > > On Fri, Mar 2, 2012 at 04:57, Vishvananda Ishaya <vishvana...@gmail.com> > wrote: >> I agree. It would be awesome if someone could actually make it work. We >> had a totally broken version using the eventlet db pool 6 months ago. >> >> Vish >> >> On Mar 1, 2012, at 4:20 PM, Joshua Harlow wrote: >> >> Sad, especially since so much is using the database :-( >> >> On 3/1/12 2:43 PM, "Adam Young" <ayo...@redhat.com> wrote: >> >> On 03/01/2012 02:48 PM, Vishvananda Ishaya wrote: >>> On Mar 1, 2012, at 9:39 AM, Adam Young wrote: >>> >>>> What would the drawbacks be? Probably the first thing people would look >>>> to from Eventlet is performance. I don't have the hard numbers to compare >>>> Eventlet to Apache HTTPD, but I do know that Apache is used in enough high >>>> volume sites that I would not be overly concerned. The traffic in an >>>> Openstack deployment to a Keystone server is going to be about two orders >>>> of >>>> magnitude less than any other traffic, and is highly unlikely to be the >>>> bottleneck. >>> How did you arrive at this number? Every user has to hit keystone before >>> making a request to any other service (unless they already have a token) and >>> each service needs to authenticate that token. Any request that hits >>> multiple services will hit keystone multiple times. Without caching, >>> keystone is by far the busiest service in an openstack install. Caching >>> should fix some of this, but I don't know that I would expect it to be two >>> orders of magnitude less. >>> >>> Vish >> >> >> Seeing as the SQL Alchemy code is blocking on each request, I suspect >> that performance is now soundly *not* a reason to want to stick with >> eventlet. My statement that Eventlet is performant is based on the >> assumption that the benefits of using Greenthreads are realized. It >> looks like that is not the case. >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
