Как стать автором
Обновить

Комментарии 12

Непонятно только одно, если данные нужны для отображения, то какая разница, как их получили: синхронно или асинхронно? Без самих данных же отрендерить страницу не получится.
Допустим на странице выводиться 1) данные из файла(например GeoIp)120 мс 2) Данные из SQL(например список продуктов) 80 мс 3) данные от web сервиса ( например виджет погоды) 300 мс. Последовательный(синхронные) сбор данных займёт 120+80+300 = 500 мс, параллельный(асинхронный) сбор данных займёт по времени столько же сколько и самый долгий 300 мс (случай со сферическим конём в вакууме). В первом случае рэндэринг начнётся через 500 мс, во втором через 300.
В этом случае понятно, но в указанном примере это 1) неочевидно совершенно 2) вообще непонятно, как у него получилось ускорение, если у енго там всего 1 вызов
Тут возможно связано с ограничением на количество одновременный обрабатываемых запросов и освобождение потоков для обработки следующих запросов.
Смысл асинхронности в том что вы не будете держать в блокировке драгоценный поток, который может использоваться для исполнения других задач.

От асинхронности скорость выполнения операций «магическим» образом не сокращается.
В чем смысл асинхронности я в курсе, я говорил об этом конкретном примере и о том, откуда у него взялось ускорение.
Он смог освободить большее количество потоков для IIS Worker'ов чтобы они смогли быстрее выполнять свои задачи(низкоуровневое IO), тем самым уменьшив время отклика для среднего запроса.

Поточное «голодание» приводит к общей потере производительности и простаивании CPU.
Подождите, как он освободил потоки для воркеров, если он в новых же потоках и запустил таски загрузки данных?
Он их занимает на очень короткий срок. Представьте если воркеру надо ждать секунду пока кто-нибудь наконец-то выйдет из блокировки и соизволит отдать поток. Или ждать 10мс, пока очередной поток наткнется на await и отпустит свой поток обратно в пул. При асинхронной модели у него больше шансов получить поток для своей работы.
В дотнетовском пуле к сожалению нет приоритетов по дефолту, так что если все потоки занять, то IIS не сможет обрабатывать входящие запросы.
Не обижайтесь, вы круто потрудились, но в следующий раз читайте хотя бы что-то о человеке, статью которого переводите. Вы наткнулись на студента-турка, который работает в туризме и делает левые сайтики на коленке. Этот не побоюсь этого слова «ламер» впервые открыл для себя то, что программы бывают не только синхронными и написал об этом целый опус.
Спасибо за совет -впредь буду.

Да какие обиды? Читая ваш комментарий, смеялся долго над собственной невнимательностью)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории