Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uvloop: Fast Python networking

magic.io

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Uvloop: Fast Python networking

#61

Post by coderdude »

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…

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.

Re: Uvloop: Fast Python networking

#62

Post by fzaninotto »

cjbprime wrote: post #7

Wow. What's the intuition for why python on top of libuv is 2x faster than node on top of libuv?

How about clustering the Node server? By default, node uses only one process. Making the server use all available processes requires a bit more work (see https://nodejs.org/docs/latest/api/cluster.html or https://github.com/Unitech/pm2) but will probably do more justice to Node.js vs Python.

Re: Uvloop: Fast Python networking

#63

Post by distracteddev90 »

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/applications I've worked on in the past 3 years (that are concerned with scale) utilize a multi-process node architecture.

The current benchmark can only claim that a single python process that spawns multiple threads is 2x faster than a single node.js process that spawns only one thread.

This fact may be interesting to some, but is irrelevant to real world performance.

[1]: https://github.com/MagicStack/vmbench/blob/master/servers/no...

[2]: https://nodejs.org/api/cluster.html

Re: Uvloop: Fast Python networking

#64

Post by 1st1 »

fzaninotto wrote: post #62
cjbprime wrote: post #7

Wow. What's the intuition for why python on top of libuv is 2x faster than node on top of libuv?

How about clustering the Node server? By default, node uses only one process. Making the server use all available processes requires a bit more work (see https://nodejs.org/docs/latest/api/cluster.html or https://github.com/Unitech/pm2 ) but will probably do more justice to Node.js vs Python.

> but will probably do more justice to Node.js vs Python.

How so? Clustering for node just makes it run in several OS processes. You can (and should) do the same for Python code, it's easy.

Re: Uvloop: Fast Python networking

#65

Post by alexchamberlain »

sandGorgon wrote: post #52
1st1 wrote: post #43

Earlier quoted context omitted.

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

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.

Re: Uvloop: Fast Python networking

#66

Post by alexchamberlain »

distracteddev90 wrote: post #63

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

Do the other benchmarkside spawn multiple processes?

Re: Uvloop: Fast Python networking

#67

Post by sharpshadow »

jamesmishra wrote: post #29
1st1 wrote: post #2

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?

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.

Re: Uvloop: Fast Python networking

#68

Post by alexchamberlain »

danappelxx wrote: post #33
1st1 wrote: post #28

Earlier quoted context omitted.

> Building on to this, how does it compare to raw libuv in c? Building something in C is very hard. uvloop wraps all libuv primitives in Python objects which know how to manage the memory safely (i.e. not to "free" something before libuv is done with it). So development time wise, uvloop is much better. As for the performance, I guess you'd be able to squeeze another 5-15% if you write the echo server in C. > I'm not…

>So development time wise, uvloop is much better. Yeah, I definitely get that. I'm just trying to see the smaller picture here. >Cython is a statically typed compiled language, it can be anywhere from 2x to 100x faster than Python. Ah, my bad for not knowing the difference between Cython and CPython. It seems to me, then, that this isn't really a fair comparison to node, is it? Naturally a statically typed language i…

I think the uvloop package is written in Cython, but the benchmarks just use Python.

Re: Uvloop: Fast Python networking

#69

Post by haberman »

coderdude wrote: post #61
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…

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.

Re: Uvloop: Fast Python networking

#70

Post by 1st1 »

distracteddev90 wrote: post #63

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 results.

Post reply on HN