Live data from Hacker News

Uvloop: Fast Python networking

magic.io

41–50 of 132 posts

Re: Uvloop: Fast Python networking

#43
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…

I'm actually thinking about writing such a framework :) I'll call it "spin".

Re: Uvloop: Fast Python networking

#44
post #2

I'm the dev behind uvloop. AMA.

No questions, just a thank you for including relevant information about the tests content, concurrency, adding percentile boxes to graphs, etc. (and the tested environment itself!) It's refreshing to see a benchmark taken seriously rather than "we tested some stuff, here are 3 numbers, victory!".

Re: Uvloop: Fast Python networking

#45
post #30

Earlier quoted context omitted.

1) What makes uvloop which is based on libuv 2x faster than node.js which is also based on libuv? 2) Can uvloop be used with frameworks like flask or django? 3) gevent uses monkey patching to turn blocking libraries such as DB drivers non-blocking, does uvloop do anything similar? If not how does it work with blocking libraries?

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…

I'm the main person in Django working on 2), and this is interesting for sure, though our current code is based on Twisted since we need python 2 compatability (there's some asyncio code, but not a complete webserver yet)

Re: Uvloop: Fast Python networking

#46
post #26
post #23

Earlier quoted context omitted.

Cool! For the client test I'm referring to, these would be long-lived clients that stay around and just TCP ping for an echo server, rather than HTTP calls that connect/disconnect. In my experience, PyPy+twisted is around 5-25x faster CPython/twisted, and smoked asyncio as well. Would be great to see how uvloop compares there, and of course, someday when PyPy supports Python 3.5, there's no reason it couldn't use uvl…

> [..] Would be great to see how uvloop compares there [..] Yep, I'm curious to see what will happen there. Do you have any suggestions on what tool to use to generate the load? > [..] someday when PyPy supports Python 3.5, there's no reason it couldn't use uvloop via cffi I'd hope. We'll figure that out! ;)

I wrote a tool to evaluate memory per connection one layer up (at websocket level), using autobahn. It works in asyncio, so it should work fine with uvloop.

https://github.com/bbangert/ssl-ram-testing/

Re: Uvloop: Fast Python networking

#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 careful use of an Ragel [C] extension to provide fast, accurate HTTP 1.1 protocol parsing. This makes the server scream without too many portability issues." -- https://github.com/mongrel/mongrel

And its successor Thin:

"Thin is a Ruby web server that glues together 3 of the best Ruby libraries in web history: (1) the Mongrel parser, the root of Mongrel speed and security" -- http://code.macournoyer.com/thin/

In case anyone is still wondering, parsing in Ruby/Python/Lua is pretty slow compared to C/C++. That's why I personally have been really interested for a long time in writing parsers in C that can be used from higher level languages. That way you can get the best of both worlds.

Re: Uvloop: Fast Python networking

#48
post #37
post #24

It is interesting that uvloop-streams is almost identical to gevent in performance. Gevent is based on libev, the project libuv was forked from. What exactly is the -streams addition that makes uvloop-streams perform so much worse than plain uvloop?

Streams implementation is a pretty big chunk of Python code, that manages flow control, buffering, and integration with coroutines. And you don't always need all that stuff when you're writing a protocol, since you can implement them more efficiently as part of protocol parser.

Is it possible to add a benchmark for gevent using raw sockets not StreamServer (assuming that adds similar overhead).

Re: Uvloop: Fast Python networking

#49
post #43

Earlier quoted context omitted.

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

I'm actually thinking about writing such a framework :) I'll call it "spin".

sounds good! Go forth!

Re: Uvloop: Fast Python networking

#50
post #48
post #37

Earlier quoted context omitted.

Streams implementation is a pretty big chunk of Python code, that manages flow control, buffering, and integration with coroutines. And you don't always need all that stuff when you're writing a protocol, since you can implement them more efficiently as part of protocol parser.

Is it possible to add a benchmark for gevent using raw sockets not StreamServer (assuming that adds similar overhead).

AFAIK, StreamServer should actually affect benchmark in a positive way. In gevent case, StreamServer isn't about high-level abstractions, it's about making sure that client sockets always have a READ flag in the IO multiplexor (epoll, kqueue etc)
Post reply on HN