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.
Uvloop: Fast Python networking
91–100 of 132 posts
Re: Uvloop: Fast Python networking
#92Asyncio is pretty fast, but as soon as you write any Python logic, request per second will drop significantly. I'm surprise uvloop is faster than node.js since libuv was developed for the latter. Kudos to the author.
Re: Uvloop: Fast Python networking
#93Earlier 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…
Re: Uvloop: Fast Python networking
#94Re: Uvloop: Fast Python networking
#95Earlier 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…
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…
1. https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html
Re: Uvloop: Fast Python networking
#97This 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…
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
#98Earlier 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)
Re: Uvloop: Fast Python networking
#99It will be great to know how this compares to async frameworks in Java, Netty and Vert.x for example, in the benchmarks.
Re: Uvloop: Fast Python networking
#100Earlier 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.
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.