Асинхронные контроллеры в ASP.NET 4 имеют смысл? - PullRequest
1 голос
/ 31 января 2011

Asp.net 2 имеет 12 потоков по умолчанию

Теперь Asp.Net 4 имеет 5000. Нам все еще нужны асинхронные контроллеры?

Ответы [ 3 ]

6 голосов
/ 31 января 2011

Нам все еще нужны асинхронные контроллеры?

Да. Асинхронные контроллеры полезны в ситуациях, когда у вас есть длительные операции, такие как сетевые вызовы, и вы не хотите монополизировать для них рабочие потоки. Тот факт, что по умолчанию существует 5000 рабочих потоков, не означает, что вы должны тратить их впустую. Это потому, что вы миллионер, что вы отдаете свои деньги? Нет.

Очевидно, что если вы не используете асинхронные контроллеры правильно, они принесут больше вреда, чем пользы.

2 голосов
/ 11 апреля 2012

MVC 4 / Dev11 делает асинхронные контроллеры более привлекательными, чем предыдущие версии.Добавьте к этому WebAPI, упрощая создание веб-сервисов.Начало комментариев Леви, чтобы их не пропустить (под превосходным ответом @ Darin Dimitrov)

Немного расширяю ответ Дарина - работают асинхронные операции ввода / вывода (для чего предназначен AsyncController)используя IOCP, а не потоки ThreadPool.Это важно, поскольку каждый поток ThreadPool имеет связанный стек 1 МБ (плюс другие накладные расходы), поэтому, если вы используете 5000 потоков ThreadPool, вы автоматически теряете 5 ГБ памяти только из-за накладных расходов!Продолжения IOCP далеко не так велики, поэтому их можно манипулировать большим количеством в любой момент времени.Потоки ThreadPool объединяются и удаляются, когда они больше не нужны, поэтому вы принимаете удар только для тех потоков, которые в данный момент активны.Но если вы выполняете много параллельной работы с CPU с ThreadPool, вы очень быстро начнете сталкиваться с проблемами памяти.Это как раз одна из причин, по которой команды C # / VB выпустили Async CTP несколько месяцев назад - чтобы попытаться решить эту проблему.

Асинхронизация для веб-службы часто имеет смысл - см. Следуетмои вызовы базы данных будут асинхронными. Часть II

Для приложений баз данных использование асинхронных операций для уменьшения количества заблокированных потоков на веб-сервере почти всегда является пустой тратой времени.Небольшой веб-сервер может легко обрабатывать больше одновременных запросов на блокировку, чем серверная часть вашей базы данных может обрабатывать одновременно.Вместо этого убедитесь, что ваши сервисные вызовы дешевы в базе данных, и ограничьте количество одновременно выполняющихся запросов числом, которое вы протестировали для правильной работы и максимизации общей пропускной способности транзакции

См. Если мои вызовы базы данных будутАсинхронный

0 голосов
/ 10 апреля 2012

4 или 5000, это не важно, это просто настройка. Вы можете установить 1 миллиард, если хотите, это не сделает ваше приложение более масштабируемым. В конце концов, ваша машина имеет только 4 ядра (или 8 или 2, но не 5000). Всегда имейте в виду, что одновременно может быть запущено столько потоков, сколько число ядер. Каждый поток, превышающий количество ядер, просто накладные расходы. Это создаст больше переключателей контекста, потребит процессор и займет больше памяти.

IO (доступ к базе данных, веб-сервис, доступ к файлам ...) не загружает процессор. Если вы делаете это синхронно, он заблокирует поток на всю длину операции. Если у вас длительная операция (5 секунд) и загрузка 1000 запросов в секунду, вы будете постоянно блокировать 5000 потоков. Таким образом, вы уже истощаете пул потоков (с настройкой 5000). Но что еще хуже, вы будете ломать свою работу переключателями контекста. Если вы делаете это асинхронно, ни один поток не будет заблокирован, ни один ресурс не будет занят, и у вас нет ограничений на количество одновременных операций ввода-вывода, которые вы можете выполнить.

Добавление большего количества потоков в пул потоков - быстрый и грязный хак, когда вы не можете позволить себе переписать свое приложение с помощью асинхронного ввода-вывода. Это не чистое решение.

...