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)." 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." 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
