MaxConcurrentRequestsPerCPU и асинхронные запросы

Question

Я использую C # 4.0, ASP.NET MVC 3 и IIS 7.0.Меня немного смущают асинхронные запросы в IIS 7. Я прочитал эту статью и несколько сообщений на форуме / блоге, но пока не нашел ответа.Вот мой вопрос,

У меня есть приложение, которое вызывает много удаленных служб.Многие из них отвечают очень медленно.Таким образом, использование AsyncController освободит потоки моего приложения.Но в приведенной выше статье Томас говорит, что IIS 7 использует Максимальное количество одновременных запросов на процессор вместо Максимальное количество параллельных потоков на процессор.Поэтому я думаю, что освобождение потоков с помощью AsyncController не повлияет на общую стабильность приложения, поскольку теперь мы обращаемся к конкретным запросам, а не к конкретным потокам.Поэтому, если у меня 6000 одновременных запросов, использование AsyncController позволит одновременно выполнять только 5000 запросов.

Обновление : я просто хочу спросить, имеет ли какое-то значение переключение на AsyncController?

Answer 1

Да, асинхронные действия позволят лучше использовать ресурсы ЦП / памяти для долгосрочных задач, связанных с сетью. Это, в конце концов, точная причина, по которой такая функция была добавлена ​​в MVC. Они позволяют вам избежать привязки 1 потока на запрос в течение длительного периода времени. Потоки являются относительно дорогими с точки зрения ресурсов процессора и памяти для создания и поддержки.

Конечно, IIS по умолчанию настроен на одновременную обработку только 5000 асинхронных запросов (на процессор), но блог, на который вы ссылаетесь, совершенно ясно, что это просто произвольное число, которое они выбрали «потому что оно большое»

Если вам нужно обрабатывать больше, и вы проверили, что ваш сервер может безопасно обрабатывать больше, тогда непременно настройте конфигурацию IIS, чтобы увеличить лимит. Хорошей идеей является наличие такого ограничения, чтобы уменьшить влияние DOS-атак и т. Д. - помимо того, что вы фактически проверили способность вашего сервера справляться с нагрузкой, вы должны позволить IIS сделать свое дело и вернуть «тоже» ошибка занята