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

Write Fast Apps Using Async Python 3.6 and Redis

eng.paxos.com

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Write Fast Apps Using Async Python 3.6 and Redis

#71

Post by est »

zzzeek wrote: post #22

> we make heavy use of asyncio because it’s more performant more performant than....what exactly? If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no. async only gives you throughput, it has nothing to do with "faster" as far as the Python interpreter / GIL / anything like that.…

> If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no

Well, actually, yes. Without async rendering, your webpage is not ready until your 1000 rows of list is placed in Python memory then rendered to HTML as a whole then returned to your browser after like 300ms of server cost.

With async rendering, your webpage's headers and such can be returned immediately, thus your first-byte-to-response time can be done under 50ms, and your page loads by enumerating the rest of 1000 rows and renders the page incrementally.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#72

Post by zzzeek »

est wrote: post #71
zzzeek wrote: post #22

> we make heavy use of asyncio because it’s more performant more performant than....what exactly? If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no. async only gives you throughput, it has nothing to do with "faster" as far as the Python interpreter / GIL / anything like that.…

> If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no Well, actually, yes. Without async rendering, your webpage is not ready until your 1000 rows of list is placed in Python memory then rendered to HTML as a whole then returned to your browser after like 300ms of server cost. W…

That's a client streaming optimization, not related to the subject at hand which is non-blocking network IO. Assume the service returns a JSON structure. It won't get to the end any faster.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#73

Post by RubyPinch »

est wrote: post #71
zzzeek wrote: post #22

> we make heavy use of asyncio because it’s more performant more performant than....what exactly? If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no. async only gives you throughput, it has nothing to do with "faster" as far as the Python interpreter / GIL / anything like that.…

> If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no Well, actually, yes. Without async rendering, your webpage is not ready until your 1000 rows of list is placed in Python memory then rendered to HTML as a whole then returned to your browser after like 300ms of server cost. W…

Well you can do all of that sync, can't you?

    def on_connection:
        send(headers)
        send(start of page)
        for row in db:
            send(row)
        send(footer)
will have the exact same effect as what you said (not like that applies regardless, I don't think jinja outputs partial renders, since its made for flask)

The performance comparison is between python managed green threads, and OS managed actual threads. You don't get any new features

Re: Write Fast Apps Using Async Python 3.6 and Redis

#74

Post by RubyPinch »

zzzeek wrote: post #22

> we make heavy use of asyncio because it’s more performant more performant than....what exactly? If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no. async only gives you throughput, it has nothing to do with "faster" as far as the Python interpreter / GIL / anything like that.…

https://magic.io/blog/uvloop-blazing-fast-python-networking/... from the makers of uvloop (for a toy example)

it seems the main bottleneck when using aiohttp is aiohttp itself, which practically makes the use of uvloop irrelevant

Re: Write Fast Apps Using Async Python 3.6 and Redis

#75

Post by est »

zzzeek wrote: post #72
est wrote: post #71

Earlier quoted context omitted.

> If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no Well, actually, yes. Without async rendering, your webpage is not ready until your 1000 rows of list is placed in Python memory then rendered to HTML as a whole then returned to your browser after like 300ms of server cost. W…

That's a client streaming optimization, not related to the subject at hand which is non-blocking network IO. Assume the service returns a JSON structure. It won't get to the end any faster.

There must exists a module like `ijson` which could incrementally generate JSON.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#76

Post by est »

RubyPinch wrote: post #73
est wrote: post #71

Earlier quoted context omitted.

> If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no Well, actually, yes. Without async rendering, your webpage is not ready until your 1000 rows of list is placed in Python memory then rendered to HTML as a whole then returned to your browser after like 300ms of server cost. W…

Well you can do all of that sync, can't you? def on_connection: send(headers) send(start of page) for row in db: send(row) send(footer) will have the exact same effect as what you said (not like that applies regardless, I don't think jinja outputs partial renders, since its made for flask) The performance comparison is between python managed green threads, and OS managed actual threads. You don't get any new features

Another point is your server can switch context to handle other requests with async.

In real world, your web page consists more than one db (like mysql + redis + some RPC calls to microservices) queries, with async apis, you can concurrently request for all queries at once and join them all at rendering.

The async benefits can add up to a much faster responsive server.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#77

Post by paulddraper »

tuxracer wrote: post #68
bysin wrote: post #63

Earlier quoted context omitted.

I'm glad you said this. There's an async cargo cult going on, where every service must be written in "performant" async code, without knowing the actual resource and load requirements of an application. From the last benchmark I ran [1] async IO was insignificantly faster than thread-per-connection blocking IO in terms of latency, and marginally faster only after we hit a large number of clients. Async IO doesn't nec…

const users = await getUsers(); const tweets = await getTweets(users); console.log(tweets); Is async code really harder to read?

Throw an exception and look at the stacktrace.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#78

Post by kazagistar »

zzzeek wrote: post #60
icebraining wrote: post #56

Earlier quoted context omitted.

I think you're talking about different things; the idea is not that you can multiplex the requests coming in, but also the requests going out to the database and etc for each web request handling function.

So on that topic, a request typically has a single transaction going out to the database so within the scope of the request, has to perform its steps in serial in any case. If it needs to make several requests to web services that aren't dependent on each other, that's an area where you can get into stacking them with some kind of concurrency construct (I'd pass it into a greenlet oriented worker pool). but this is a…

> a request typically has a single transaction going out to the database

Its typical because people are still in a "single thread single transaction ORM crud" model of thinking. "Its linear because thats how it is"?

Re: Write Fast Apps Using Async Python 3.6 and Redis

#79

Post by RubyPinch »

est wrote: post #76
RubyPinch wrote: post #73

Earlier quoted context omitted.

Well you can do all of that sync, can't you? def on_connection: send(headers) send(start of page) for row in db: send(row) send(footer) will have the exact same effect as what you said (not like that applies regardless, I don't think jinja outputs partial renders, since its made for flask) The performance comparison is between python managed green threads, and OS managed actual threads. You don't get any new features

Another point is your server can switch context to handle other requests with async. In real world, your web page consists more than one db (like mysql + redis + some RPC calls to microservices) queries, with async apis, you can concurrently request for all queries at once and join them all at rendering. The async benefits can add up to a much faster responsive server.

Yes, those are threads when handled by the OS / greenthreads when handled by the program.

a program with threads can support multiple requests simultaneously. a program with green threads can support multiple requests simultaneously.

You arn't giving any reasons why green threads in python perform better than threads in the OS.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#80

Post by davesque »

matthewaveryusa wrote: post #67
zzzeek wrote: post #22

> we make heavy use of asyncio because it’s more performant more performant than....what exactly? If I need to load 1000 rows from a database and splash them on a webpage, will my response time go from the 300ms it takes without asyncio to something "more performant", like 50ms? Answer: no. async only gives you throughput, it has nothing to do with "faster" as far as the Python interpreter / GIL / anything like that.…

It buys you the stack size of each thread which only matters if you have a stupid amount of connections. In this article[1] the author makes a comparison between the 2 models and 7000 concurrent users will chew up 450MB of stack space. Of course this is adjustable. [1] http://byteworm.com/evidence-based-research/2017/03/04/compa...

How do you save on stack space with asyncio? Don't you have to keep the coroutine object in memory somewhere?
Post reply on HN