Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Serginio1, Вы писали:

ЕМ>>>Какое переключение Вы имеете в виду?
S>>Переключение между потоками
S>>Переключение контекста

ЕМ>О том, что переключение контекста занимает "значительное время", было уместно говорить лет двадцать назад, когда железо было в несколько раз медленнее, а софт — в сотни раз менее тормозным. Для того, чтобы воообще как-то заметить накладные расходы на переключение контекста, его нужно переключать минимум несколько тысяч раз в секунду. Чтобы эти расходы стали заметны на фоне прикладного кода, этот код должен быть идеально вылизан, чего нынче почти встречается. Ну а затраты памяти на поток, по нынешним меркам, и вовсе ничтожны. При современном размашистом подходе к разработке софта, о накладных расходах на потоки имеет смысл начинать думать не раньше, чем количество потоков в приложении достигнет нескольких сотен.

Ну а на серверах как ты считаешь сколько соединений может быть? и сколько запросов в секунду?
Там не то что сотни, сотни тысяч запросов в секунду. Заметь я писал про сервера.
Там и редисы ставят и прочую лабуду.
https://robinsedlaczek.com/2014/05/20/improve-server-performance-with-asynchronous-webapi/
https://stackoverflow.com/questions/36683468/can-using-async-await-give-you-any-performance-benefits

Кроме того скоро наступает эпоха IoT и лишними ресурсы не бывают

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Serginio1, Вы писали:

ЕМ>>>Какое переключение Вы имеете в виду?
S>>Переключение между потоками
S>>Переключение контекста

ЕМ>О том, что переключение контекста занимает "значительное время", было уместно говорить лет двадцать назад, когда железо было в несколько раз медленнее, а софт — в сотни раз менее тормозным. Для того, чтобы воообще как-то заметить накладные расходы на переключение контекста, его нужно переключать минимум несколько тысяч раз в секунду. Чтобы эти расходы стали заметны на фоне прикладного кода, этот код должен быть идеально вылизан, чего нынче почти встречается. Ну а затраты памяти на поток, по нынешним меркам, и вовсе ничтожны. При современном размашистом подходе к разработке софта, о накладных расходах на потоки имеет смысл начинать думать не раньше, чем количество потоков в приложении достигнет нескольких сотен.

Ну а на серверах как ты считаешь сколько соединений может быть? и сколько запросов в секунду?
Там не то что сотни, сотни тысяч запросов в секунду. Заметь я писал про сервера.
Там и редисы ставят и прочую лабуду.
https://robinsedlaczek.com/2014/05/20/improve-server-performance-with-asynchronous-webapi/

For a small number of concurrent requests (100), synchronous and asynchronous results were pretty close, with 47/48 requests per second and 2065/2027 median latency. The difference was more drastic for 1000 concurrent requests, with sync attaining 65 req/s and 10507 ms median latency, and async attaining 98.86 req/s and 10080 ms, with significantly lower latency deviation (1506 ms vs 8000 ms). I have not seen any failed requests at all.

At the moment I am not able to test more than 1000 requests for unknown reason, and my machine is a humble Pentium E6800 with 6GB of memory running Windows 7.

https://stackoverflow.com/questions/36683468/can-using-async-await-give-you-any-performance-benefits

Кроме того скоро наступает эпоха IoT и лишними ресурсы не бывают