Highload web server with lots of blocking workflows?

Question

Django

Anyone in the know, please explain. There is, for example, unicorn or some other server.
As a rule, when configuring the server, the maximum number of processes and workers is set, thus. multithreading falls entirely on the web server. In the event that a thread-blocking operation occurs during the execution of a request, it will block the entire thread and it will not be available to new connections. Accordingly, if we have a limit of 2 threads, and 2 users have loaded them completely (which, of course, is wild for most web applications, but nevertheless), then new users will not be able to receive answers to their requests until at least one of the threads will not be released. It is a fact. Just checked.
django has a built-in server that works without any brakes at all, it just creates a new thread for each request - no blocking at all, no restrictions, etc. In this case, multithreading falls entirely on the conscience of the system - where there is free processor time, the request will fly to that core (well, as I understand it). This is also evident from the experiment - we make a bunch of requests, they load different cores in turn.
QUESTIONS.
Why can't this scheme be used in production? Why is everyone categorically against this approach and strongly recommend setting the number of processes and threads manually?
Ultimately, if the percent is loaded, then there will be no resources for the new thread. Even if it is created anyway, then the operations in this thread will simply wait for the processor to be released - this does not make the scheme less attractive if the web server were to distribute requests among threads.
In both cases, a high load will result in a long wait time, or, as far as I understand, if something is limited by the web server, it can simply reject overload requests, but this is also a dubious advantage, starting from the position that it is better to respond to the user late than not to respond at all.
Поделитесь своими соображениями на эту тему или посоветуйте нормальную литературу/статьи, которые бы не начинались со слов "я не профессионал в этой теме, но..." или "статья не претендует ни на что, просто..."
Спасибо.

Answer 1

Each tool has its own purpose. We have all heard common phrases about driving nails with a microscope and cracking nuts with a hammer. The main feature of Django is fast and easy development. Multithreading in itself is not simple, and even more so in Python. Therefore, Django is single-threaded and synchronous. Everything in it was designed with sequential execution in mind, and trying to use parallel will lead to problems. You can use its execution in a multi-process environment, but this is no longer a question for Django, but for the runtime. For example, to uWSGI. You can read about dynamic worker allocation in uWSGI here . In Django itself, you should try to make the views return the result as quickly as possible. It is more correct to design them so that long and blocking operations can be shifted toCelery. Если же задача именно держать долго и упорно коннект с клиентом, то лучше посмотреть в сторону асинхронных фреймворков Tornado, aiohttp или Gevent.

Answer 2

А что вы понимаете под потоками ? объекты ОС или объекты внутреннего представления системы исполнения кода ?
если первое - то не оч хорошо создава/удалять
если второе - то это называется зеленые процессы (потоки). Тут уже как среда исполнения сама разрулит.
Например для Erlang можно создавать миллионы зеленых процессов и все будет летать как надо.