Open Stack

Hello, Kevin.

On Fri, Feb 7, 2014 at 12:32 AM, Kevin Conway <kevinjacobconway at gmail.com>wrote:

> 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
> http://www.youtube.com/watch?v=Obt-vMVdM8s is absolutely required
> watching.
>

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.

Green threads give us a powerful way to manage concurrency where it counts:
> I/O.
>

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.


> 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.
>

There are threaded WSGI servers, there are even some greenthreaded ones. We
shouldn't burden ourselves with managing those processes, threads and
greenthreads.


> 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.
>

But we still get one thread of execution, just as with native threads
(because of GIL).

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.
>

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.

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

Please take a look at this well-known benchmark:
http://nichol.as/benchmark-of-python-web-servers, 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.

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.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140207/e678b324/attachment.html>