<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote" style>Hello, Kevin.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Feb 7, 2014 at 12:32 AM, Kevin Conway <span dir="ltr"><<a href="mailto:kevinjacobconway@gmail.com" target="_blank">kevinjacobconway@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">There's an incredibly valid reason why we use green thread abstractions like eventlet and gevent in Python. The CPython implementation is inherently single threaded so we need some other form of concurrency to get the most effective use out of our code. You can "import threading" all you want but it won't work the way you expect it to. If you are considering doing anything threading related in Python then <a href="http://www.youtube.com/watch?v=Obt-vMVdM8s" target="_blank">http://www.youtube.com/watch?v=Obt-vMVdM8s</a> is absolutely required watching.</div>

</div></blockquote><div><br></div><div style>I suggest use threading module and let it be either eventlet's greethreads (after monkey-patching) or built-in (OS) threads depending on deployment scenario you use.</div>
<div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Green threads give us a powerful way to manage concurrency where it counts: I/O.</div>

</div></blockquote><div><br></div><div style>And that's exactly where GIL is released and other native threads are executed, too. So they do not provide benefits because of overcoming GIL but because of smart work with network connections. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> Everything in openstack is waiting on something else in openstack. That is our natural state of being. If your plan for increasing the number of concurrent requests is "fork more processes" then you're in for a rude awakening when your hosts start kernel panicking from a lack of memory.</div>

</div></blockquote><div><br></div><div style>There are threaded WSGI servers, there are even some greenthreaded ones. We shouldn't burden ourselves with managing those processes, threads and greenthreads.</div><div> </div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> With green threads, on the other hand, we maintain the use of one process, one thread but are able to manage multiple, concurrent network operations.</div>

</div></blockquote><div> </div><div style>But we still get one thread of execution, just as with native threads (because of GIL).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">In the case of API nodes: yes, they should (at most) do some db work and drop a message on the queue. That means they almost exclusively deal with I/O. Expecting your wsgi server to scale that up for you is wrong and, in fact, the reason we have eventlet in the first place.</div>

</div></blockquote><div><br></div><div style>But I'm sure it's not using eventlet's potential. In fact, I'm sure it doesn't since DB calls (they are the most often ones in API, aren't they?) block anyway and eventlet or any other coroutine-based framework can't do much about it while application server can spawn more processes and/or threads to handle the load.</div>

<div style><br></div><div style>I would like to refer to Adam Young here: <a href="http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/">http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/</a> - as he provides more point in favor of external WSGI server (native calls, IPv6, extensibility, stability and security).</div>

<div style><br></div><div style>Please take a look at this well-known benchmark: <a href="http://nichol.as/benchmark-of-python-web-servers">http://nichol.as/benchmark-of-python-web-servers</a>, where mod_wsgi performs better than eventlet in the simple case and eventlet is not present in the second case because of lack of HTTP/1.1 support.</div>

<div style><br></div><div style>Of course it's a matter for benchmarking. My point is that we can develop our services with a simple threaded server and as long as they work correctly we can always bring in greenthreads by monkey-patching later if and only if they prove themselves better than other options in the market. Our codebase should not be dependent on one single eventlet's or anyone's other WSGI server or reactor loop.</div>

<div><br></div></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>