Open Stack

On 7/7/14, 3:57 PM, Matt Riedemann wrote:
>
>
>
> Regarding the eventlet + mysql sadness, I remembered this [1] in the
> nova.db.api code.
>
> I'm not sure if that's just nova-specific right now, I'm a bit too
> lazy at the moment to check if it's in other projects, but I'm not
> seeing it in neutron, for example, and makes me wonder if it could
> help with the neutron db lock timeouts we see in the gate [2].  Don't
> let the bug status fool you, that thing is still showing up, or a
> variant of it is.
>
> There are at least 6 lock-related neutron bugs hitting the gate [3].
>
> [1] https://review.openstack.org/59760
> [2] https://bugs.launchpad.net/neutron/+bug/1283522
> [3] http://status.openstack.org/elastic-recheck/


yeah, tpool, correct me if I'm misunderstanding, we take some API code
that is 90% fetching from the database, we have it all under eventlet,
the purpose of which is, IO can be shoveled out to an arbitrary degree,
e.g. 500 concurrent connections type of thing, but then we take all the
IO (MySQL access) and put it into a thread pool anyway.

Why are we doing this?   Assuming we currently have a 500+ concurrent DB
connections use case, has anyone demonstrated this actually working? 

Keep in mind, I'm a total dummy with async - other than the usual client
side JS/AJAX experience, I have very little "purely async API"
experience.    But I've been putting out these questions on twitter and
elsewhere for some time and nobody is saying that I'm totally getting it
wrong.  I *should* be wrong.