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

91–100 of 134 posts

Re: Write Fast Apps Using Async Python 3.6 and Redis

#91

Post by netheril96 »

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.

Well, threads also switch context.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#92

Post by netheril96 »

Waterluvian wrote: post #45
bobbyi_settv wrote: post #31

Earlier quoted context omitted.

You normally use something like redis to store the state. If you were going to share state in memory between threads, how would you handle the case where the second request goes to a different server or that the process has restarted? You'd need redis anyway, so you might as well just use it in all cases.

I get that everyone's responses are thinking some big public thing. I'm thinking small toy implementation for my home network. The toy experiment is how to do what's trivial in Node with Python. Mainly because I like working with python. I think the answer might be: Python is the wrong tool for the job.

Is multithreading really necessary for a toy?

Re: Write Fast Apps Using Async Python 3.6 and Redis

#93

Post by tomchristie »

zebra9978 wrote: post #86
tomchristie wrote: post #36

Earlier quoted context omitted.

One thing to clarify here. Swagger/OpenAPI use JSON Schema in order to describe parameters and response structures. The rest of the schema work will start to fall into place pretty quickly now that we've got the groundwork done. Swagger generation based on the annotations will be one of the features, but there'll be plenty more to get excited about too.

any particular reason you are using BSD license ? With all due respect, this does not cover a patent grant like the Apache license and could be a poison pill for companies to adopt.

I just had a quick scan over the licenses of other projects used for server side projects. Projects using BSD/MIT include Node, Go, Rails, Django, and Flask.

I'm happy with the choice.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#94

Post by zzzeek »

makmanalp wrote: post #87
zzzeek wrote: post #60

Earlier quoted context omitted.

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…

> this is already going to be a heavy web request with multiple web service calls Sure, but it can now be a less heavy web request! ¯\_(ツ)_/¯ > a request typically has a single transaction going out to the database The fact of the matter is, as applications develop, become richer, and grow larger, it becomes less and less uncommon to have more than one query per page. Especially in the context of larger organizations…

> it becomes less and less uncommon to have more than one query per page.

I said transaction, not query. A database transaction is on a single connection at a time and queries are performed via the transaction serially.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#95

Post by [deleted] »

weberc2 wrote: post #49
Waterluvian wrote: post #17

Earlier quoted context omitted.

I have never found a good example of a Python web server that provides some mechanism for statefulness. Is it just fundamentally not possible to have shared state among requests handled by the threads of a process? Sanic's examples seem to be the same as Flask's: self-contained function calls attached to endpoints. I keep hitting a wall with Python when I want to do something like: 1. subscribe to a websocket connect…

Flask lets you share state between requests; just have the route methods reference some global variable. You could also apply the route decorator to an instance method (although probably not using the decorator syntax).

[deleted]

Re: Write Fast Apps Using Async Python 3.6 and Redis

#96

Post by mkj »

netheril96 wrote: post #92
Waterluvian wrote: post #45

Earlier quoted context omitted.

I get that everyone's responses are thinking some big public thing. I'm thinking small toy implementation for my home network. The toy experiment is how to do what's trivial in Node with Python. Mainly because I like working with python. I think the answer might be: Python is the wrong tool for the job.

Is multithreading really necessary for a toy?

It probably is for long-polling or websockets?

https://github.com/mkj/wort-templog/blob/master/web/templog.... is my not-quite-toy example - a single process runs from uwsgi with Bottle (like Flask) and gevent. The long polling waits on a global Event variable that's updated by another request, nice and simple.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#97

Post by dagw »

zzzeek wrote: post #94
makmanalp wrote: post #87

Earlier quoted context omitted.

> this is already going to be a heavy web request with multiple web service calls Sure, but it can now be a less heavy web request! ¯\_(ツ)_/¯ > a request typically has a single transaction going out to the database The fact of the matter is, as applications develop, become richer, and grow larger, it becomes less and less uncommon to have more than one query per page. Especially in the context of larger organizations…

> it becomes less and less uncommon to have more than one query per page. I said transaction, not query. A database transaction is on a single connection at a time and queries are performed via the transaction serially.

In many non trivial cases I tend to find that I have to query several different databases to render a single page.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#98

Post by merb »

zzzeek wrote: post #94
makmanalp wrote: post #87

Earlier quoted context omitted.

> this is already going to be a heavy web request with multiple web service calls Sure, but it can now be a less heavy web request! ¯\_(ツ)_/¯ > a request typically has a single transaction going out to the database The fact of the matter is, as applications develop, become richer, and grow larger, it becomes less and less uncommon to have more than one query per page. Especially in the context of larger organizations…

> it becomes less and less uncommon to have more than one query per page. I said transaction, not query. A database transaction is on a single connection at a time and queries are performed via the transaction serially.

not everything is transaction centric. and also before I make a transaction I mostly fetch various stuff before and sometimes after.

and also my count example, it just makes no sense to have the count and the list data called inside a transaction (ok there are cases, but these are way more rare, because mostly It's not to bad to give users a wrong count, you don't need strict Serializability)

Re: Write Fast Apps Using Async Python 3.6 and Redis

#99

Post by devwastaken »

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?

Thats hardly applicable async code. You're awaiting the actual async operations, which originally have to be distributed asynchronously from the main thread for these async operations to execute, and at that point its the same speed as just doing sync operations inside of an async operation.

Actual asychronocity, usually with event based systems, gets very ugly, very fast, because you end up having to make callback chains and queueing up your async work. There can be a good benefit to doing it, but its going to be a lot less readable than most sync code, and sometimes not any faster, in the case of Node.JS and its community forcing the usage of async function in places where they don't need to be used.

Re: Write Fast Apps Using Async Python 3.6 and Redis

#100

Post by icebraining »

cwilkes wrote: post #90
icebraining wrote: post #61

Earlier quoted context omitted.

Not really, you can use a multiprocessing.Manager to share a plain old dict or list across multiple worker processes: https://docs.python.org/3/library/multiprocessing.html#shari...

I think the OP was talking about different VMs behind a load balancer where there is no shared memory at all.

Wasn't my impression (using worker processes in the same machine is common), but fair enough. On the other hand, message passing across machines is overrated. We run a SaaS service on 25 VMs with no communication between them for regular operation.
Post reply on HN