Live data from Hacker News

Uvloop: Fast Python networking

magic.io

91–100 of 132 posts

Re: Uvloop: Fast Python networking

#91
post #87

Looks good. Wonder why these benchmarks never include an actual database. I'm using firebase with nodejs and no matter how many requests per second my server can respond with, it's ultimately constrained by data requests and memory (ie how many connections can I wait on). When I see numbers like 50k requests per second it's meaningless, unless I have no database or some kind of in memory cache only db.

It's not meaningless for new gen apps which trade a lot of db request for message passing. In micro-services app, when you update something, you propagate the change, and you have x client update for one db requests instead of having x + 1 db requests. In that context, broacasting quickly to a lot of clients is important.

Re: Uvloop: Fast Python networking

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

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

Re: Uvloop: Fast Python networking

#95
post #70

Earlier quoted context omitted.

There is nothing misleading about the benchmarks. It is explicitly said that ALL frameworks were benchmarked in single-process and single-thread modes. Yes, in production you should run your nodejs app in cluster, your Python apps in a multiprocess configuration, and you should never use GOMAXPROCS=1 for your go apps in production! Running all benchmarks in multiprocess configuration wouldn't add anything new to the…

The main premise in my comment is that the benchmarks do not resemble real world performance, and are therefore misleading. The comment above ( https://news.ycombinator.com/item?id=11626762 ) further expands on why these kinds of benchmarks, although interesting, have no real value. Each implementation does something wildly different and responds to different inputs with completely different outputs. To put it metaph…

I guess I look at the benchmarks in a bit different light.

These benchmarks are primarily comparing event loops and their performance. TCP benchmark is very fair, HTTP - maybe not so much. The point is to show that you can write super fast servers in Python too, just have a fast protocol parser.

As for the HTTP benchmarks, I plan to add more stuff to httptools and implement a complete HTTP protocol in it. Will rerun the benchmakrs, but I don't expect more than 20% performance drop.

Re: Uvloop: Fast Python networking

#96

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

This is also what inspired the uwsgi[1] protocol in the uWSGI project[2].

1. https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html

2. https://uwsgi-docs.readthedocs.io/en/latest/

Re: Uvloop: Fast Python networking

#97
post #74

This isn't a fair comparison. the "HTTP server" presented isn't doing any checks / validation that a typical web server does. Compare https://github.com/MagicStack/vmbench/blob/master/servers/as... to https://github.com/nodejs/node/blob/master/lib/_http_outgoin... https://github.com/nodejs/node/blob/master/lib/_http_server.... https://github.com/golang/go/blob/master/src/net/http/server... The benchmark is almost equ…

Keep in mind that the HTTP server in the benchmarks actually uses the httptools parser, which is a full-blown HTTP parser. A lot of heavy-lifting is done by the parser.

I plan to add a complete HTTP protocol implementation to httptools, but honestly, I don't expect it to be more than 20% slower.

Re: Uvloop: Fast Python networking

#98

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…

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.

Re: Uvloop: Fast Python networking

#100
post #43

Earlier quoted context omitted.

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

Go for it! An async python web framework with the speed of Go and the ecosystem of python would be a killer app.

We are actually working on a project like this with Tygs (https://github.com/Tygs/tygs, which will use crossbar.io), and right now it's taking ages just to get the app life cycle right.

Indeed, we want to make it very easy to use, especially a clean/discoverable API, simple debugging, clear errors, etc. Which is the stuff async frameworks are not good at, and an incredible added value.

It's a lot more work we initially thought. When you are doing async, you now think, not with a sequence of actions ordered in time, but with events. So for your framework to be usable, you must provide hooks to:

    - do something at init
    - register a component
    - do something when a component is registered
    - do something once it's ready
    - do something when there is an error
    - do something when it shuts down
With minimum boiler plate, and maximum clear error handling when the user try to do it at the wrong time or in the wrong way.

But, we learned while coding the project that, with asyncio, exceptions in coroutine don't break the event look (except KeyboardInterrupt which is a weird hybrid) while exceptions from the loop do break it.

Plus you have to make a nice setup, which auto starts the event loop with good default so that people don't have to think about it for simple apps. But it must be overridable, and handle the case where your framework is embeded inside an already started event loop, and make it easy to do so.

It's one of the strong point of gevent: you don't have to think about it. With asycio/twisted, you have the benefit a explicit process switch and parallelism, but you need to pay the price with verbosity and complexity. We try to create a balance, and it's turns out to be harder than expected.

Then you have to make clear error reporting, especially iron the implementation mixing Task, Futures, coroutine functions and coroutines. Provide helpers so that common scheduling is done easily...

And you haven't even talked about HTTP yet. This is just proper asyncio management. This is why nobody made a killer framework yet : it's a looooooot of work, it's hard, and it's very easy to get it wrong. Doing like but async doesn't cut it.

Post reply on HN