Ограничить параллелизм ИЛИ НЕ ограничить параллелизм? (в пределах одного запроса ASP.NET)

Question

Существует множество ответов на вопрос, КАК ограничить параллелизм асинхронных операций ввода-вывода и / или их продолжений - с помощью пользовательского планировщика, SemaphorSlim и т. Д. Мой вопрос: имеет ли смысл делать это в стандартном сценарии ASP.NET MVC / WebAPI?

У нас есть типичный корпоративный API, который служит бэкендом для ориентированного на клиента SPA. Многие запросы API включают вызов десятков нисходящих веб-сервисов, которые мы в настоящее время в основном преобразовали в асинхронный ввод-вывод с помощью TAP (async / await). Многие из этих вызовов удаленной службы запускаются параллельно, без ожидания, а затем ожидаются массово с использованием Task.WhenAll. Иногда, когда AllAll выполняется для фиксированного числа задач, а иногда мы запускаем удаленный вызов для элемента в коллекции - что приводит к появлению неизвестного (но обычно небольшого, менее дюжины) количества задач и затем ожидания их с WhenAll.

Как я понимаю , это заставляет продолжения этих задач (то есть логику, которая десериализует их ответы) планироваться в ThreadPool. Это приводит к моему вопросу: не приведет ли параллельное выполнение этих продолжений, связанных с процессором, к чрезмерному давлению на ThreadPool? Должны ли мы разрабатывать какое-то промежуточное программное обеспечение, которое ограничивало бы параллелизм продолжений асинхронных задач ввода-вывода, запускаемых внутри одного запроса, путем планирования их в пользовательском планировщике?

Это позволило бы улучшить масштабируемость нашего приложения, уменьшив количество потоков ThreadPool, выделенных для любого данного запроса, что позволило бы обслуживать более параллельные запросы до того, как мы начнем исчерпывать потоки ThreadPool (или получить удушение) ростом ThreadPool)?

Или это довольно бесполезно, и мы должны просто доверять способности ThreadScheduler + ThreadPool по умолчанию планировать все задачи на доступные ядра ЦП для любого количества одновременных запросов?

К вашему сведению, каждый пытается ответить:

Это довольно зрелая система в очень крупной компании, которую тщательно изучают десятки экспертов (в том числе и я), занимающихся производством в одном штате США, готовящихся к выпуску на национальном уровне. Такие предложения, как «сначала измерить», «узнать, являетесь ли вы IO по сравнению с процессором», «попробовать AppInsights» и «не пытаться быть умнее, чем Microsoft», - это самые первые вещи, о которых мы сами, очевидно, подумали. Уровень руководства, к которому мы стремимся, больше похож на: Кто-нибудь здесь внедрил полностью асинхронную систему ASP.NET Web API на национальном уровне в США и имеет реальный опыт работы с асинхронным / когда выполняется параллелизм?

Answer 1

@ tarun-lalwani отметили несколько замечаний в комментариях

Но я упомяну твердый совет никогда не предоптимизировать. Сегодня настольный компьютер среднего уровня может легко обрабатывать пул потоков из 16 (что в целом может обрабатывать сотни ожидающих задач), хороший сервер может обрабатывать гораздо больший пул потоков, чем тот, сколько стоит ваше время по сравнению со стоимостью замены или новый сервер, вероятно, менее 6 месяцев, очень возможно, менее 3 месяцев.

Любые проблемы с производительностью сводятся к узким местам, система может работать только так быстро, как самые медленные узкие места. Таким образом, устранение этих конкретных узких мест в реальной системе - это то, как улучшить производительность. Как масштабировать эти группы узких мест - как улучшить масштабируемость. Между настольным и серверным оборудованием все еще много различий, поэтому я еще раз подчеркну, что вам нужно увидеть реальные показатели, а не показатели in-vitro, прежде чем приложить недели / месяцы усилий для решения «проблемы», которая может не быть там.

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

Таким образом, имеет смысл только ограничить процесс, если и когда он станет проблемой.