Uvloop: Fast Python networking • Hacker News Board

Re: Uvloop: Fast Python networking

#111

Post by dcosson » Wed, May 04, 2016, 4:22 PM UTC

sandGorgon wrote: post #39

1st1 wrote: post #30

Earlier quoted context omitted.

1) I don't know :( I've answered a similar question in this thread with a couple of guesses. 2) No, they have a different architecture. Although I heard that there is a project to integrate asyncio into django to get websockets and http/2. 3) asyncio/uvloop require you to use explicit async/await. So, unfortunately, the existing networking code that isn't built for asyncio can't be reused. On the bright side, there a…

> 2) No, they have a different architecture Having a web framework (a next generation Flask if you will) built ground up with concurrency is the missing key. I have used Flask for many years, but this is the right time to introduce a new framework - because of the internal restructuring and slowdown of Flask's maintainers (and I say this with the utmost respect). If you are keen, this has the potential to be the kill…

One problem with this is that the entire ecosystem has to get on board with async. Maybe a new framework would make it compelling enough, who knows.

This was/is the big issue with Tornado, IMO (and Tornado has been around for ages in framework time). Tornado is only async if the entire call stack all the way down to the http socket is async, using callbacks instead of returning values. This means that any 3rd party client library you use has to be completely written asynchronously, and none are in python. So you end up with a lot tedious work re-implementing http client libraries for Twilio or Stripe or whatever you're using.

I'm curious to see where asyncio goes in python, but I'm a bit skeptical after seeing how much of a pain it was to use Tornado on a large web app. In the meantime I'll be using Gevent + Flask, which isn't perfect since it adds some magic & complexity but has the huge upside of letting you keep using all the libraries you're used to.

Re: Uvloop: Fast Python networking

#112

Post by mayhew » Wed, May 04, 2016, 4:27 PM UTC

sandGorgon wrote: post #98

shuzchen wrote: post #75

Earlier quoted context omitted.

There is already http://www.tornadoweb.org/en/stable/ which is python3 compatible and shipped in production software across lots of companies (last I heard hipmunk and quora uses it)

Tornado is excellent... But Flask is better than excellent. The mental map of Flask is incredible. Tornado is a little hard to grok. Now one may argue that Tornado is hard by choice...to not mask the complexity. But then we have node..the most hip of frameworks out there. Node's true innovation was not performance, but to simplify the mental model of async. Obviously there's all the callback hell and all..but still.

I'm pretty sure both Node and Tornado have the same mental model of async. Both have callbacks and both have async/await functionality that makes it look more like blocking code.

The main benefit of Node as I see it is that the entire Node community uses the same IO Loop whereas Python's community is fragmented between normal sync code and multiple different IO Loops (asyncio will probably help with this).

Re: Uvloop: Fast Python networking

#113

Post by takeda » Wed, May 04, 2016, 4:30 PM UTC

sharpshadow wrote: post #67

jamesmishra wrote: post #29

Earlier quoted context omitted.

It looks like uvloop requires Python 3.5. How practical is it to create a fork for companies stuck on Python 2.7?

Today it should be good practice to use containers with Python 2.7 and 3.5 or any other versions you like. With that you can solve most szenarios.

Python is actually designed in such way that you can install multiple major versions and they can coexist perfectly fine together.

For example you can install python 2.6, 2.7, 3.3, 3.4, & 3.5 all on one host without any conflicts. The limitation is that many distributions prefer to not maintain different versions of supposedly the same language.

If you use RedHat or CentOS you can just use https://ius.io/ and get access to the other python versions. This is one of few repos that makes sure the packages don't conflict with system ones.

Re: Uvloop: Fast Python networking

#114

Post by takeda » Wed, May 04, 2016, 4:33 PM UTC

jquast wrote: post #110

1st1 wrote: post #31

Earlier quoted context omitted.

Not really practical. uvloop is designed to work in tandem with asyncio, which is a Python 3-only module. asyncio, in turn, requires 'yield from' support, something that Python 2 doesn't have.

The 'Trollius' module backported asyncio to Python 2, requiring syntax changes, though. For example "yield from" to "yield From()". Work on Trollius was stopped a few weeks ago, there wasn't enough interest/use. Call for interested maintainers, http://trollius.readthedocs.io/deprecated.html#deprecated

The problem with Trollius was that packages that asyncio packages needed explicitly to add support for it to work (because Python 2 does not have yield from) Several packages (I remember aiohttp was one of them) did not want to do that.

Re: Uvloop: Fast Python networking

#115

Post by mayhew » Wed, May 04, 2016, 4:36 PM UTC

sametmax wrote: post #109

jsjohnst wrote: post #93

Earlier quoted context omitted.

Forgive me if I'm misunderstanding what you're looking for, but doesn't Tornado fit that bill?

Tornado still too low level. - It's verbose compared to flask. - It reinvent the wheel, while flask uses great components such as werkzeug. - If you want to make a component, it's complex. - It doesn't come battery included for the Web like Django, just the bare minimum. - It misses the opportunity to provide task queues, RPC or PUB/SUB which are key components to any modern stacks are made easily possible by having…

Yeah, it's hard for Python to compete with languages like Go and Erlang that multiplex IO in the runtime.

Re: Uvloop: Fast Python networking

#116

Post by 1st1 » Wed, May 04, 2016, 4:48 PM UTC

rattray wrote: post #105

1st1 wrote: post #2

I'm the dev behind uvloop. AMA.

This is awesome! How does it compare to PyPy? Once PyPy3 is available, will this work with it?

> Once PyPy3 is available, will this work with it?

We'll find a way!

Re: Uvloop: Fast Python networking

#117

Post by 1st1 » Wed, May 04, 2016, 5:05 PM UTC

cesarbs wrote: post #108

haberman wrote: post #47

> However, the performance bottleneck in aiohttp turned out to be its HTTP parser, which is so slow, that it matters very little how fast the underlying I/O library is. This is exactly the same observation that motivated the Mongrel web server for Ruby, 10 years ago this year. "Mongrel is a small library that provides a very fast HTTP 1.1 server for Ruby web applications. [...] What makes Mongrel so fast is the caref…

On a related note, we go through great lengths in the Kestrel HTTP server [0] (which also uses libuv) to have fast HTTP parsing. As an example, we attempt to read the method and the HTTP version as longs and compare them to pre-computed longs in order to have fast comparisons and reuse strings containing standard methods and versions (reducing memory allocation is the main driver of our optimizations) [1], so we don'…

Have you benchmarked it?

Re: Uvloop: Fast Python networking

#118

Post by 1st1 » Wed, May 04, 2016, 5:13 PM UTC

danappelxx wrote: post #102

Sean1708 wrote: post #60

Earlier quoted context omitted.

> It seems to me, then, that this isn't really a fair comparison to node, is it? Isn't node written in C?

Yes, but JavaScript is still a dynamic, garbage collected language.

Most of nodejs internals are in C++ on top of libuv. Only a thin layer of JS interfaces wrap that.

Python is also a dynamic, GCed language. uvloop is built with Cython, which uses the Python object model (and all of its overhead!), and CPython C-API extensively (so it's slower than a pure C program using libuv).

Re: Uvloop: Fast Python networking

#119

Post by igravious » Wed, May 04, 2016, 5:37 PM UTC

haberman wrote: post #47

> However, the performance bottleneck in aiohttp turned out to be its HTTP parser, which is so slow, that it matters very little how fast the underlying I/O library is. This is exactly the same observation that motivated the Mongrel web server for Ruby, 10 years ago this year. "Mongrel is a small library that provides a very fast HTTP 1.1 server for Ruby web applications. [...] What makes Mongrel so fast is the caref…

How much of a parsing stack can you build atop of Ragel? I gave Ragel a good look over recently when checking out parsers for Ruby because Ragel has a Ruby binding. I chose A Ruby PEG† library (Parslet) because I decided that there was too much of a gap between the low level finite automata machinery that Ragel provides and the parsing generation that I was looking for. Was I wrong to decide that, I wonder.

† On a related note, I'm finding it difficult finding (fast) GLR or GLL parser generators for Ruby

Re: Uvloop: Fast Python networking

#120

Post by ericfrederich » Wed, May 04, 2016, 6:25 PM UTC

haberman wrote: post #69

coderdude wrote: post #61

Earlier quoted context omitted.

It's the best of both worlds but doesn't shield you from the worst of one of the worlds. Untrusted input is still reaching code that has direct access to system memory. Hopefully not, anyway. But probably. Still, it's the way to go if performance is key.

Very true. Thankfully fuzzing tools are getting better all the time. LLVM's libfuzzer is great.

I'd recommend to watch this: https://www.youtube.com/watch?v=y0hyqzR6hIY

He goes into detail about how these types of libraries are particularly difficult or impossible to fuzz. He uses OpenSSL as an example but I would imagine an http library being similar.