[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.

[emacsen]

Yes, 100% it depends on many factors. 100€ euro a month = 1200€ euro a year... Now if a developer can address that in 15 minutes- wonderful, but if it takes her a week... have you won very much, because it's not just the time calculation but it's the other would this same developer could have been doing in this same time.

Moreover, you're right to calculate this per year because maybe you'll throw this entire code away in a year, or maybe it will become the key code for something else, and you'll need to optimize it anyway.

Even sometimes having a meeting to discuss the performance is not cost effective. Six employees around a table for an hour discussing whether or not to improve the performance of 1200€ a year is not cost efficient.

But then again, sometimes it really is. In one environment we were asked to use some tooling on top of the OS that reduced performance by 5%. It was some management toy that would have made the Linux boxes do the same thing as the Windows boxes, but there was a performance penalty of 5%...

5% of 1000 machines is 50 machines, or just over one rack of servers, and so we could go back to management and say "The performance penalty of this is over a rack of machines. Are you sure you want this?" and then they can decide if it's worth it or not.

[Hamuko]

Server upgrade costs can vary wildly depending on what it entails. The cost of adjusting your EC2 Auto-Scaling Group maximum instance count will be very different than contacting HPE sales department.

[marcosdumay]

At this point it seems that only mainframes can get more expensive than cloud auto-scaling.

But yeah, some places have a very expensive acquisition procedure. To the point that the labor in buying expensive things costs more than the thing itself. But those places "solve" the problem by buying large batches, and the hardware x developer costs comparison don't change much.

[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).