Scope of asynchronous programming?

Question

Programming

Hello.
I touched on this rather popular topic for the web as asynchronous programming, there are many articles on the Internet on this topic, so it’s not so difficult to figure it out, but I still have a number of questions that I would like to clarify.
As I understand it, asynchronous programming is not a panacea and in some cases it leads to performance losses, as an example, complex mathematical calculations are mentioned that can block the execution flow that runs through events.
Do I understand correctly that in this case, loading and reading files is acceptable, as well as heavy queries to the database will not lead to this, but on the contrary, with asynchronous execution, they will give an increase in overall performance, since the processor time will be occupied by other things, in this case, only waiting for reading will occur / records, which cannot be said with math calculations where processor time is directly used for calculations.
Am I understanding the difference correctly?
And if I understand correctly, then for typical web sites that mainly read and write to the database and return after the results of display requests, well, uploading files to the server is also a common case, the option with asynchronous execution will be more productive, since in this case CPU time won't be wasted waiting right?

Answer 1

Asynchronous code allows you to execute code in parallel in one thread, the total profit is that memory is saved because. each thread requires memory for itself. Essentially everything.
In total, this allows you to run 1M parallel tasks and more, saving memory.
The code does not run faster, and often slower. your implementation of task switching is slower than the OS and CPU do.
The gain can be due to the fact that you run tasks in parallel, when in a multi-threaded you will block them with each other. But if you make a separate thread for each task, then the asynchronous one will not be faster.
The asynchronous approach makes sense (only) when the task has long locks (web sockets, network downloads with freezes) - when the thread weighs and waits for an event, then instead of 10k threads, you can put the whole task in one asynchronous thread.
Everything would be fine, but the problem is that the complexity of asynchronous code is much higher in various aspects, the total time can be spent many times more (a year for a project instead of 4 months, for example).
Therefore, it is better to use asynchrony where it is justified (for web sockets), and do the rest of the project "classically". And now, because of fashion, some people try to do everything entirely with asynchronous code, then sometimes after a year or two, articles appear that asynchrony is not worth it, and they are poured over in the comments that they say you don’t know how to cook.
Более разумным видится использование файберов/корутин, но эту тему не сильно развивают.

Answer 2

Грубо говоря - профит в ситуациях, в которых процесс простаивает во время выполнения операции (например, указанные в вопросе ситуации).
Соответственно, если работа происходит синхронно - в это время невозможна работа с другими запросами. Если юзаются "системные" потоки - уже лучше, но накладные расходы относительно высоки. Ну и существуют подходы, позволяющие лучше утилизировать 1 поток (нодовое event-driven, golang-е горутины и прочее).

Answer 3

На серверной стороне если протокол HTTP и сервер Apache/nginx, то асинхронность и многозадачность используется абсолютно всегда, на клиентской это AJAX и т.п., AJAX оптимизирует и клиентскую и серверную сторону, если только сервер не будет опрашиваться слишком часто.