Hacker News Reader

Comment by WhyNotHugo | Hacker News Reader

Also, async views allow for better scaling. Say your view needs to make an API call to a third party service within a request-response cycle. Currently, this will block an entire worker/thread while doing a blocking request.

With async, we can use async HTTP libraries and scale these WAY better.

View on HN

Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about.

Async is beneficial when you make multiple blocking (http) request to a resource at the same time and later fold that into one response. Parallel stuff. Or when you are forced to run a single thread. Or when you are memory bound.

Reality is that most requests depend on previous requests quite often. In the latter case there is no benefit in terms of speed for the user.

I know this is unpopular opinion though :-)

Might be unpopular but still good to stick to it. I tend to associate excessive enthusiasm for pythons async await framework as a sign of immaturity and potential for doing things without understanding them fully. I’d never trust async code from anyone except the best python engineers. Most of them out there can’t even debug linear code, adding async to the mix only makes it worse. At least you can trust the time stamps.

>I tend to associate excessive enthusiasm for pythons async await framework as a sign of immaturity and potential for doing things without understanding them fully.

Couldn't it be the inverse? I.e. your inexeperience with async code in other languages, and not understanding it fully, translating into "new thing aversion"?

I think my experience in async in other languages has shown how rough async in Python is.

Unless async is the default python, it will always be an after thought and introduce needless complexity when working on large projects that require a lot of external libs.

Or when accidentally some blocking database driver is used, even when django's ORM is async, a query with mongodb's driver is not async. Or just the filesystem... This harms performance badly, especially if the idea was to run only a few threads.

Other than that, it has benefits too! :-)

And indeed, there's an important caveat in the Django 4.1 docs;

Note that, at this stage, the underlying database operations remain synchronous, with contributions ongoing to push asynchronous support down into the SQL compiler, and integrate asynchronous database drivers....

https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchro...

> Or just run 20 workers and let the OS handle async.

That just means you can only handle 20 concurrent requests before performance drops off a cliff. If the third-party service you are talking to is slow, then you’ll just end up with 20 workers all waiting for the service to respond, while other requests pile up. With async, those workers could still be handling other requests. Adding more workers because you are blocking on i/o works for low traffic services, not for anything remotely busy.

> Adding more workers because you are blocking on i/o works for low traffic services, not for anything remotely busy.

Yes.

That just means in very bad cases, you can only handle 1 "concurrent request" before performance drops off a cliff. If the third-party service you are talking to is that slow, then you’ll just end up with bufferbloat (high latency in hidden queues) waiting for the service to respond, requests piling up.

With async, unless you know what you're doing and handle back pressure, work pile up even worse, the service stops working and you get 0 throughput instead.

Agree! Up the number of workers to 40, fix your application in another way... or indeed go with async stuff! ;-)

I was just saying that async quite often is not of much help and just complicates things. Of course it has its use! Your case is a great example of converting a django view into an async view.

Why would you block a process that could use CPU cycles to do something useful just to wait on I/O? With the right primitives async is not "hard" nor inconvenient. Maybe you're referring to concurrency?

No I am referring to async, really. Accidentally blocking operations like open() or psycopg or mongodb or some included library which (accidentally) uses any of that stuff. Basically any library requiring requests is not usable. Or worse: open().

It can be hard to determine if something is doing something blocking and if it is, it is hard to debug. Especially in python world which, unlike javascript, was not async from the start.

I don't understand, are you saying async is hard or that a poor implementation is a source of issues (e.g. async function that calls sync primitives)? Because I totally agree with the latter but I have no idea what "hard" means. Very little changes in terms of syntax (assuming support for async/await ops) or reasoning.

Java's Loom model really does feel like the future of concurrency in many ways.

So now if the requests become slow because of the third party or whatever, and take 1 second each, you have a max performance of 20 rps.

With async instead you would still be able to handle thousands of rps.

> Or just run 20 workers and let the OS handle async. OSes are pretty good at this. Async is pretty hard to reason about.

    def slow_sync_view(request):
        # these requests won't be executed in parallel;
        # async version could eliminate this extra latency
        foo = requests.get('https://www.google.com/humans.txt').text
        bar = requests.get('https://checkip.amazonaws.com').text
        return HttpResponse(f'{foo}\n{bar}')

Basic concurrent.futures.ThreadPoolExecutor solves this problem.

https://docs.python.org/3/library/concurrent.futures.html#co...

I think you are being down voted because a straight port of this code to async would still run one request after the other.

You would have to queue one task for each request in the event loop and then await for them both to gain some parallelism in the I/O section of the code.

Reply on news.ycombinator.com