[openstack-dev] [all] Replace eventlet with asyncio
Dolph Mathews
dolph.mathews at gmail.com
Thu Feb 26 15:48:00 UTC 2015
On Wed, Feb 25, 2015 at 4:12 AM, Victor Stinner <vstinner at redhat.com> wrote:
> Hi,
>
> > I also just put up another proposal to consider:
> > https://review.openstack.org/#/c/156711/
> > """Sew over eventlet + patching with threads"""
>
> My asyncio spec is unclear about WSGI, I just wrote
>
> "The spec doesn't change OpenStack components running WSGI servers
> like nova-api. The specific problem of using asyncio with WSGI will
> need a separated spec."
>
> Joshua's threads spec proposes:
>
> "I would prefer to let applications such as apache or others handle
> the request as they see fit and just make sure that our applications
> provide wsgi entrypoints that are stateless and can be horizontally
> scaled as needed (aka remove all eventlet and thread ... semantics
> and usage from these entrypoints entirely)."
>
+1!
>
> Keystone wants to do the same:
> https://review.openstack.org/#/c/157495/
> "Deprecate Eventlet Deployment in favor of wsgi containers
>
> This deprecates Eventlet support in documentation and on invocation
> of keystone-all."
>
We don't just *want* to do the same: we actually made eventlet a second
class citizen long ago (that's going to be a tough first step for many
projects that are tightly coupled with eventlet). We have little reason to
continue supporting eventlet, so we're finally proposing it for official
deprecation.
> I agree: we don't need concurrency in the code handling a single HTTP
> request: use blocking functions calls. You should rely on highly efficient
> HTTP servers like Apache, nginx, werkzeug, etc. There is a lot of choice,
> just pick your favorite server ;-) Each HTTP request is handled in a
> thread. You can use N processes and each process running M threads. It's a
> common architecture design which is efficient.
>
> For database accesses, just use regular blocking calls (no need to modify
> SQLAchemy). According to Mike Bayer's benchmark (*), it's even the fastest
> method if your code is database intensive. You may share a pool of database
> connections between the threads, but a connection should only be used by a
> single thread.
>
> (*)
> http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/
>
> I don't think that we need a spec if everybody already agree on the design
> :-)
>
> Victor
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150226/293aadaf/attachment.html>
More information about the OpenStack-dev
mailing list