Open Stack

On 06/08/2016 11:05 PM, Chris Friesen wrote:
> On 06/07/2016 04:26 PM, Ben Meyer wrote:
>> On 06/07/2016 06:09 PM, Samuel Merritt wrote:
>>> On 6/7/16 12:00 PM, Monty Taylor wrote:
>>>> [snip]
>>>>
>>>> I'd rather see us focus energy on Python3, asyncio and its pluggable
>>>> event loops. The work in:
>>>>
>>>> http://magic.io/blog/uvloop-blazing-fast-python-networking/
>>>>
>>>> is a great indication in an actual apples-to-apples comparison of what
>>>> can be accomplished in python doing IO-bound activities by using
>>>> modern
>>>> Python techniques. I think that comparing python2+eventlet to a fresh
>>>> rewrite in Go isn't 100% of the story. A TON of work has gone in to
>>>> Python that we're not taking advantage of because we're still
>>>> supporting
>>>> Python2. So what I've love to see in the realm of comparative
>>>> experimentation is to see if the existing Python we already have
>>>> can be
>>>> leveraged as we adopt newer and more modern things.
>>>
>>> Asyncio, eventlet, and other similar libraries are all very good for
>>> performing asynchronous IO on sockets and pipes. However, none of them
>>> help for filesystem IO. That's why Swift needs a golang object server:
>>> the go runtime will keep some goroutines running even though some
>>> other goroutines are performing filesystem IO, whereas filesystem IO
>>> in Python blocks the entire process, asyncio or no asyncio.
>>
>> That can be modified. gevent has a tool
>> (http://www.gevent.org/gevent.fileobject.html) that enables the File IO
>> to be async  as well by putting the file into non-blocking mode. I've
>> used it, and it works and scales well.
>
> Arguably non-blocking isn't really async when it comes to reads.  I
> suspect what we really want is full-async where you issue a request
> and then get notified when it's done.

So when it comes to Swift or Glance where you have to transfer large
amounts of data between the HTTP client and HTTP server....under WSGI,
the only way to make it truly cooperative for eventlet, gevent, etc is
to use non-blocking File I/O. These situations also reveal how
uncooperative green threads are too since if you can keep the data
pipeline full (e.g the read is continuous because the OS is able to
quickly service it) then one greed thread will take over and block the
others. Non-blocking I/O is only part of the solution, not the entire
solution.

Furthermore, the constraint of the web head having to provide the data
transfer makes the full-async offload with a notification impossible for
data transfer services like Swift. Tools like uvloop make great strides
in providing better environments for doing cooperative tasks than what
existed prior, and some of the articles comparing it to the various
tools - both alone and in combination - make for some fascinating
possibilities and solutions. Most likely the best solution here is going
to be going to Py3's asyncio+uvloop+non-blocking I/O on the files in
order to hit the throughput for Swift.

uvloop (first commit 2015-11-01) is newer than Swift's hummingbird
(2015-04-20, based on
https://github.com/openstack/swift/commit/a0e300df180f7f4ca64fc1eaf3601a1a73fc68cb
and github network graph) so it would not have been part of the
consideration.

$0.02

Ben