81–90 of 132 posts
I'm the dev behind uvloop. AMA.
It looks like uvloop requires Python 3.5. How practical is it to create a fork for companies stuck on Python 2.7?
Not very, it's an alternative event loop for asyncio[0] which was introduced in 3.4 and builds upon other Python 3 features (e.g. `yield from`)
I'm the dev behind uvloop. AMA.
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…
Earlier quoted context omitted.
You totally should. I think people are hungry for a next gen async web framework... And if it leverages Python 3, then so much the better. Flask cannot go here even if it wants because its core philosophy is to be WSGI compliant. You don't necessarily have to adhere to that. Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database…
> Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database interaction until it's too late. I strongly advise against this. One of the reasons Flask is so attractive is the fact that it does not enforce any database on you. Thanks to its decoupled design you can use it purely as a routing library, which is great! Letting the framew…
what frequently happens is a web framework without a thought for any kind of DB interaction (or as you put it... a routing library). In things like an async web framework, that could leave users hanging. For example, psycopg vs psycopg2 vs psycogreen vs psycopg2-cffi . Tell me which one to use and benchmark it.
I agree, its a fine line. And we can keep going back and forth whether a framework should "recommend" or not recommend. But in case like this - I think there will NOT be a lot of libraries that will be compliant with the async usecase. I would hope that this framework will recommend... but not ship "batteries included".
The benchmarks for node.js are terribly misleading. The node.js implementations only ever spawn a single process, and thus node is only running on a single core and uses only a single thread. Specifically, the http server example(1), doesn't even bother using the standard library provided Cluster module(2). Cluster is specifically designed for distributing server workloads across multiple cores. All node.js services/…
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 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 metaphorically, if you put a car engine in two completely different chassis and then race them on a track, you aren't gaining any real insight into relative performance of the engine in the two vehicles.
Also, just to be clear, my qualms are with the benchmarks alone, I think the library is great! Thanks for all the hard work :)
I'm the dev behind uvloop. AMA.
It looks like uvloop requires Python 3.5. How practical is it to create a fork for companies stuck on Python 2.7?
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.
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.
These days you would probably want to write the parser part in Rust, with a small amount of unsafe code to implement a C-compatible API that could then be called from Python, or wherever. I did this for some regexp-based log parsing code written in Python, and saw a considerable (2-3x) performance win. The main outstanding issue is that Rust isn't as easy to distribute as C to random end users (e.g. it likely require…
Earlier quoted context omitted.
You totally should. I think people are hungry for a next gen async web framework... And if it leverages Python 3, then so much the better. Flask cannot go here even if it wants because its core philosophy is to be WSGI compliant. You don't necessarily have to adhere to that. Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database…
If such a framework was built around asyncio, do we really need yet another database layer? 1 of the best things about Flask is it doesn't reinvent the wheel.
Most database libraries don't play very well with non blocking code. In fact nodejs dB libraries were specifically designed for this.
Building async frameworks is not trivial - http://initd.org/psycopg/docs/advanced.html#async-support
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…
How so? It uses a binding to http-parser, just like nodejs.