Live data from Hacker News

Uvloop: Fast Python networking

magic.io

11–20 of 132 posts

Re: Uvloop: Fast Python networking

#11
This is quite interesting, but I don't find req/sec very interesting at all. These should be about matters of concurrency, that is, how much is being done at once, not how many req/sec overall are done (which could almost be explained away purely by the gains in lower latency).

These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low.

A few questions I'd like to see answered.

How many clients can you connect to each server, and have each one ping once per 5 mins, before the CPU gets overloaded?

How much memory is used per connection?

How does PyPy+Twisted fair in this?

Re: Uvloop: Fast Python networking

#12
post #7

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

Two things I'd check first:

1. The benchmarks make servers generate a huge number of objects, so maybe, the GC is under too much pressure.

2. Another possibility is that the v8 JIT can't optimize some JS code in nodejs, or does a poor job.

That said, only careful profiling can answer your question :)

Re: Uvloop: Fast Python networking

#13
post #2

I'm the dev behind uvloop. AMA.

I'm working on a Python CLI that uses asyncio/aiohttp to make and process requests to a 3rd party API. Anyways, I ran into the 10,000 socket problem today and ended up using a semaphore, that actually boosted the overall performance. Why is that? Is it just because the CPU is overwhelmed otherwise?

Re: Uvloop: Fast Python networking

#14
post #6
post #2

I'm the dev behind uvloop. AMA.

> at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework I did not see any benchmarks in the repo to support this. How was this statistic determined?

Not sure what you mean, the benchmark section lists ~40k packets/s for nodejs and asyncio, ~100k for uvloop (for 1KiB packages, similar difference for 10 and 100 KiB) - and ~20k req/s for nodejs, and ~37k for uvloop w/httptools. Interestingly, uvloop pulls ahead for 100KiB request size for the http case.

Re: Uvloop: Fast Python networking

#15
post #6
post #2

I'm the dev behind uvloop. AMA.

> at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework I did not see any benchmarks in the repo to support this. How was this statistic determined?

Building on to this, how does it compare to raw libuv in c?Personally, I'm not surprised that python (especially cython) is faster than node in this case, but I still need to see how much less overhead there is to node.

Re: Uvloop: Fast Python networking

#16
Asyncio 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

#18
Also note that David Beazley (google him if you're not aware) has a competitor to asyncio, which arguably is also a direct competitor to this called curio:

http://curio.readthedocs.io/en/latest/

The caveat is that it uses the new async/await coroutine bits that just landed in Python 3.5, so it only works with Python 3.5+. He also gave a talk on concurrency in python recently at last year's PyCon:

https://www.youtube.com/watch?v=MCs5OvhV9S4

Re: Uvloop: Fast Python networking

#19
post #2

I'm the dev behind uvloop. AMA.

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?

Re: Uvloop: Fast Python networking

#20
post #11

This is quite interesting, but I don't find req/sec very interesting at all. These should be about matters of concurrency, that is, how much is being done at once, not how many req/sec overall are done (which could almost be explained away purely by the gains in lower latency). These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low. A few questions I'd like to see answered. How many c…

> These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low.

I've just update the post with more details on HTTP benchmarks and attached the correct full-results file [1]. The concurrency level for HTTP benchmarks is 300, not 10.

To answer other questions, I'll have to run some benchmarks tomorrow :)

[1] http://magic.io/blog/uvloop-blazing-fast-python-networking/h...

Post reply on HN