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

101–110 of 132 posts

Re: Uvloop: Fast Python networking

#101

Post by hasenj »

jagger27 wrote: post #55
sandGorgon wrote: post #52

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…

Since spin is conflicting, may I suggest spyn? Gets that nice little Python 'py' in there.

Can also be read as "spine".

Re: Uvloop: Fast Python networking

#102

Post by danappelxx »

Sean1708 wrote: post #60
danappelxx wrote: post #33

Earlier quoted context omitted.

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

> It seems to me, then, that this isn't really a fair comparison to node, is it? Isn't node written in C?

Yes, but JavaScript is still a dynamic, garbage collected language.

Re: Uvloop: Fast Python networking

#103

Post by sigil »

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…

Check out http-parser for Python: https://pypi.python.org/pypi/http-parser

This uses Dahl's original http_parser.c FSM. With a little work you can write a WSGI handler around it. Highly recommend.

Re: Uvloop: Fast Python networking

#104

Post by sandGorgon »

sametmax wrote: post #100
continuations wrote: post #58

Earlier quoted context omitted.

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

you are doing excellent work. you should totally join hands with the OP and make something great!!

Re: Uvloop: Fast Python networking

#106

Post by takeda »

breathesalt wrote: post #13
1st1 wrote: 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?

Are you making all connections within a single session?

Not long ago I saw example here that someone was creating a new session for every single connection. This is not very optimal way of using it. If you use it within same session, aiohttp will make use of keep-alive, which in turn will reuse existing connections and reduce overhead. You also won't need to use a semaphore, since you can define limit in TCPConnector.

Why you had performance issues? As other said, you were making thousands of connections, each socket need to be in TIME_WAIT state for 2 minutes after closing (limitation of TCP, SCTP does not have this problem). So if you use all connections within short time, you'll essentially run out of them. Some people use tcp_tw_reuse/recycle, and that solves this issue, but that makes your connections no longer follow RFC and you might encounter strange issues later on. The advice above should resolve your problem without any hacks.

Re: Uvloop: Fast Python networking

#107

Post by sametmax »

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

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…

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

I'd like to chat with you about this, share ideas for API, and architectures. Even if we don't work to each others, we can benefit from sharing ideas about what should a next gen framework look like in Python.

Re: Uvloop: Fast Python networking

#108

Post by cesarbs »

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…

On a related note, we go through great lengths in the Kestrel HTTP server [0] (which also uses libuv) to have fast HTTP parsing. As an example, we attempt to read the method and the HTTP version as longs and compare them to pre-computed longs in order to have fast comparisons and reuse strings containing standard methods and versions (reducing memory allocation is the main driver of our optimizations) [1], so we don't have to allocate those strings on every request. We do a similar thing for headers [2]. We also manage a lot of our own memory, despite using a garbage collected language [3].

[0] https://github.com/aspnet/KestrelHttpServer

[1] https://github.com/aspnet/KestrelHttpServer/blob/3a424f6abac...

[2] https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Mic...

[3] https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Mic...

Re: Uvloop: Fast Python networking

#109

Post by sametmax »

jsjohnst wrote: post #93
sandGorgon wrote: post #39

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…

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

Tornado still too low level.

    - It's verbose compared to flask.
    - It reinvent the wheel, while flask uses great components such as werkzeug.
    - If you want to make a component, it's complex.
    - It doesn't come battery included for the Web like Django, just the bare minimum.
    - It misses the opportunity to provide task queues, RPC or PUB/SUB which are key components to any modern stacks are made easily possible by having persistent connections.
    - It ignores async/await potential of unifying threads/process/asyncio and don't allow easy multi-cpu.
Don't get me wrong, I think tornado is a great piece of software, but it's not match against innovative projects we see in Go or NodeJS such as Meteor.

Re: Uvloop: Fast Python networking

#110

Post by jquast »

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

Earlier quoted context omitted.

It looks like uvloop requires Python 3.5. How practical is it to create a fork for companies stuck on Python 2.7?

Not really practical. uvloop is designed to work in tandem with asyncio, which is a Python 3-only module. asyncio, in turn, requires 'yield from' support, something that Python 2 doesn't have.

The 'Trollius' module backported asyncio to Python 2, requiring syntax changes, though. For example "yield from" to "yield From()".

Work on Trollius was stopped a few weeks ago, there wasn't enough interest/use. Call for interested maintainers, http://trollius.readthedocs.io/deprecated.html#deprecated

Post reply on HN