<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 4:12 AM, Victor Stinner <span dir="ltr"><<a href="mailto:vstinner@redhat.com" target="_blank">vstinner@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> I also just put up another proposal to consider:<br>
> <a href="https://review.openstack.org/#/c/156711/" target="_blank">https://review.openstack.org/#/c/156711/</a><br>
> """Sew over eventlet + patching with threads"""<br>
<br>
</span>My asyncio spec is unclear about WSGI, I just wrote<br>
<span class=""><br>
"The spec doesn't change OpenStack components running WSGI servers<br>
</span>like nova-api. The specific problem of using asyncio with WSGI will<br>
need a separated spec."<br>
<br>
Joshua's threads spec proposes:<br>
<br>
"I would prefer to let applications such as apache or others handle<br>
the request as they see fit and just make sure that our applications<br>
provide wsgi entrypoints that are stateless and can be horizontally<br>
scaled as needed (aka remove all eventlet and thread ... semantics<br>
and usage from these entrypoints entirely)."<br></blockquote><div><br></div><div>+1!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Keystone wants to do the same:<br>
<a href="https://review.openstack.org/#/c/157495/" target="_blank">https://review.openstack.org/#/c/157495/</a><br>
"Deprecate Eventlet Deployment in favor of wsgi containers<br>
<br>
This deprecates Eventlet support in documentation and on invocation<br>
of keystone-all."<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
(*) <a href="http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/" target="_blank">http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/</a><br>
<br>
I don't think that we need a spec if everybody already agree on the design :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
Victor<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>