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

121–130 of 132 posts

Re: Uvloop: Fast Python networking

#121

Post by halayli »

RedCrowbar wrote: post #90
halayli wrote: post #74

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…

> This isn't a fair comparison. the "HTTP server" presented isn't doing any checks / validation that a typical web server does. How so? It uses a binding to http-parser, just like nodejs.

Parsing is just a small part of an http server. You can check the links I posted to see how much work is involved in validating http headers (after parsing), and creating http responses.

Re: Uvloop: Fast Python networking

#122

Post by haberman »

ericfrederich wrote: post #120
haberman wrote: post #69

Earlier quoted context omitted.

Very true. Thankfully fuzzing tools are getting better all the time. LLVM's libfuzzer is great.

I'd recommend to watch this: https://www.youtube.com/watch?v=y0hyqzR6hIY He goes into detail about how these types of libraries are particularly difficult or impossible to fuzz. He uses OpenSSL as an example but I would imagine an http library being similar.

> He goes into detail about how these types of libraries are particularly difficult or impossible to fuzz.

I just watched the video on 2x and I don't think that's a fair summary. He seems positive on fuzzing in general and mentions that fuzzing found two extremely tricky bugs in libsndfile and flac.

He does point out that there are some cases like OpenSSL that are particularly difficult to fuzz completely because they are encrypted and heavily stateful, creating transient keys on the fly and such. I don't think HTTP has this problem, for the most part.

Cool to see a video of Erik de Castro Lopo though -- I've worked with that guy since the early 2000s when I was working on Audacity (which uses his excellend libsndfile internally -- or at least did at the time).

Re: Uvloop: Fast Python networking

#125

Post by haberman »

igravious wrote: post #119
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…

How much of a parsing stack can you build atop of Ragel? I gave Ragel a good look over recently when checking out parsers for Ruby because Ragel has a Ruby binding. I chose A Ruby PEG† library (Parslet) because I decided that there was too much of a gap between the low level finite automata machinery that Ragel provides and the parsing generation that I was looking for. Was I wrong to decide that, I wonder. † On a re…

I think you're right: the gap between Ragel and what you want in higher-level languages is too wide to make a stack out of it IMO.

I'm working on what I consider a parsing stack. The key observation, in my opinion, is that you need a way of representing structured data in the high-level language that is both rich and efficient. I think Protocol Buffers can serve that role.

Once you have the structured data representation, you can write parsers to read/write it. But you want the parsers to be independent of how you represent the structured data in any one language.

Re: Uvloop: Fast Python networking

#126

Post by occasionalreedr »

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?

C Python uses ref counting, whereas Node/V8 uses GC. Ref counting schemes generally use much less memory and GC scans can be expensive when there's a lot of new data, as is the case for a web server.

Re: Uvloop: Fast Python networking

#127

Post by gJigsaw »

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

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

https://github.com/pyGrowler/Growler "A micro web-framework using asyncio coroutines and chained middleware."

Re: Uvloop: Fast Python networking

#128

Post by sametmax »

mayhew wrote: post #115
sametmax wrote: post #109

Earlier quoted context omitted.

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…

Yeah, it's hard for Python to compete with languages like Go and Erlang that multiplex IO in the runtime.

It's not hard for the language, but we don't have the proper framework yet. Because such a framework is quite a task.

Re: Uvloop: Fast Python networking

#129

Post by igravious »

haberman wrote: post #125
igravious wrote: post #119

Earlier quoted context omitted.

How much of a parsing stack can you build atop of Ragel? I gave Ragel a good look over recently when checking out parsers for Ruby because Ragel has a Ruby binding. I chose A Ruby PEG† library (Parslet) because I decided that there was too much of a gap between the low level finite automata machinery that Ragel provides and the parsing generation that I was looking for. Was I wrong to decide that, I wonder. † On a re…

I think you're right: the gap between Ragel and what you want in higher-level languages is too wide to make a stack out of it IMO. I'm working on what I consider a parsing stack. The key observation, in my opinion, is that you need a way of representing structured data in the high-level language that is both rich and efficient. I think Protocol Buffers can serve that role. Once you have the structured data representa…

I've spent the last little while browsing through the upb and gazelle repos. I'm struggling to get a high-level overview of what you want to do. I'm curious though because what you're saying here on HN intrigues me.

Re: Uvloop: Fast Python networking

#130

Post by jsjohnst »

sametmax wrote: post #109
jsjohnst wrote: post #93

Earlier quoted context omitted.

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…

We will have to agree to disagree on many of your points as they are mostly personal opinions, but the last one is flat wrong. Tornado has for a long time had great support for fully leveraging all CPU cores. Happy to show sample code if you like.
Post reply on HN