[Uberphallus]

It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0].

Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.

[0]https://news.ycombinator.com/item?id=29128107

[emacsen]

This is a question that's largely impossible to answer, but there's a performance vs developer (or business) time calculation to be made.

More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue?

Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that's saving you 20 physical servers worth of performance.

But often the answer is that it's not worth it. That 2% performance increase on a set of 10 servers is not calculable, and more often even a 10% performance benefit is only noticeable on some specific task, not as a constant overhead.

On the other hand, developer time is expensive and can often be best spend on core functionality.

If Django is, let's say even 20% slower than an async framework like FastAPI, but it's going to save three developers a week of development time to implement a feature in Django, then that's probably a much cheaper solution.

I've used Django, Flask, Sanic and FastAPI[1] and today I often choose FastAPI for my projects, but I think Django is still what I'd turn to if I needed to make a full fledged web application quickly, despite its performance not being as good as FastAPI.

[1] Before I learned Django, I also used Zope, and TurboGears.

[Zababa]

That remind me of a meeting a few days ago where we were discussing if we should add another server or spend a bit more time developing something. After some time, I asked about the server cost, and it ended up being something like 100€ a month more to not have to worry about performance for the next year. In that case the decision was easy enough, but maybe some organisations have fixed server budgets and developers. For those, being able to trade developer time for performance, even if it seems inefficient, may be better than nothing.

[konschubert]

> if your backend throws requests against external (and potentially blocking) services and you have the "audacity" of wanting to keep answering your clients.

If you have enough processes/threads running, the CPU scheduler should take care of that , no?

[fer]

Yes, but more processes means more memory footprint, almost 4 times as much in that benchmark, something the author didn't cover. Threading solves that, but it's way more prone to shooting yourself in the foot than async, especially since it's not baked into Django (i.e. you gotta cook your own solutions over callbacks, polling, etc).