Когда вам действительно нужна асинхронность в веб-фреймворке?

многие другие ответы здесь исходят из перспективы UI (desktop/mobile app), а не из перспективы веб-сервера.

Async стал модным словом в .net, и MS представила его в Web API 2, чтобы можно было обрабатывать больше запросов, пока другие ждут завершения ввода-вывода.

async и await были представлены в .NET 4.5 / VS 2012. Однако, ASP.NET имеет возможность асинхронного запроса с .NET 2.0-очень давно. И им пользовались люди.

что async и await принести в таблицу асинхронный код это легко поддерживать.

пока я вижу выгоду от этого, это действительно проблема?

ключевые преимущества async на сервере есть масштабируемость. Проще говоря, async масштаб задач намного лучше, чем потоки.

комментарий@Joshua является ключевым в отношении памяти; поток принимает значительный объем памяти (и не забывайте стек режима ядра, который не может быть выгружен), в то время как async запрос буквально занимает всего несколько сотен байт.

есть также разрыв, чтобы рассмотреть. .NET threadpool имеет ограниченную скорость впрыска, поэтому, если вы не установите свой minWorkerThread count к значению намного выше, чем вам обычно нужно, а затем, когда вы получите всплеск трафика, некоторые запросы будут 503, прежде чем .NET сможет прокрутить достаточно потоков для их обработки. async держит свои темы свободный (насколько это возможно), поэтому он лучше обрабатывает разрывной трафик.

архитектура x64 имеет 30000 + потоков в пуле потоков, поэтому, если у вас нет столько одновременных пользователей на вашем веб-сайте, действительно требуется асинхронность?

@Joshua снова прав, когда он указывает, что вы, вероятно, думаете об ограничении очереди запросов (по умолчанию 1000 для очереди IIS и 5000 для ASP.NET ограничение запроса). Важно отметить, что однажды эта очередь заполняется (во время бурного трафика), новые запросы отклоняются с 503.

даже если у вас так много одновременных пользователей без кэширования, я уверен, что SQL Server упадет с таким количеством запросов?

теперь это совершенно другой вопрос.

я даю говорить на ThatConference 2013 конкретно async сервера. Одна часть этого разговора-ситуации, когда async не помогает (мое обновление Twitter).

здесь отличный пост в блоге здесь это занимает позицию, что асинхронные вызовы db просто не стоят усилий. Важно отметить предположения в этом посте:

1. в то время, когда сообщение было написано, асинхронные веб-серверы были трудными. В эти дни у нас есть async и все больше библиотек предлагают асинхронные API (например, Entity Framework).
2. в архитектура предполагает один веб-сервер с один SQL сервер. Это очень распространенная установка традиционно, но быстро меняется сегодня.

здесь async серверы действительно светят, когда ваш бэкэнд также может масштабироваться. Например, веб-служба, Azure SQL, кластер NoSQL и т. д. Пример: я пишу сервер MVC/WebAPI, который использует Azure SQL и хранилище для своего бэкэнда (для всех практических целей я могу действовать так, как будто они имеют бесконечную масштабируемость); в этом случае я собираюсь сделайте мой сервер async. В таких ситуациях вы можете масштабировать свой сервер 10x или более, используя async.

но если у вас есть только один сервер SQL Server (и нет планов изменения на Azure SQL), то нет смысла делать ваш веб-сервер async потому что вы все равно ограничены своим бэкэндом.