МСУDualcoreон подходит лишь для мелкого распараллеливания в пределах одной процедурки ?
Да, под локальную задачу для конкретного метода. И то нужно тысячу раз подумать и проверить, действительно ли нужно это и какой мы получим выйгрыш.
Пример рачета:
1. Банальный пример, пул потоков может максимум выделить твоему веб-сервису 50 тредов.
2. В сервисе 10 методов, в каждом юзается по дополнительному фоновому потоку (async/await, TPL, Threads).
3. Методы равномерно используются внешними потребителями. То есть ты линейно размазываешь 50 тредов на (10 * 2) методов, получая 2.5 потока на метод.
4. Предположим, при пиковых нагрузках сервиса методы уже не будут справляться и будут запрашивать дополнительную песочницу (поток) для работы, а ей в свободном доступе нет, т.к. соседние методы юзают аж по 2 потока на задачу.
5. Профит? Да хрен там было.

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

Парень задает правильный вопрос(могут быть внешние поставщики данных, которых не расстреляешь) и
сразу видно, что ты с этим дело не имел. Расчеты левые, тк за 30 секунд может прийти еще надцать запросов и никаких трэдов и тасков не хватит. Посему сервисы должны иметь интерфейс с тасками, максимально использовать новый API с asyn\await, которые НЕ СОЗДАЮТ НИКАКИХ ФОНОВЫХ ПОТОКОВ. Для вызовов БД это можно сделать.

ЗЫ Стандартный трэдпул имел 25 во времена гороха - Net 3.5.
ЗЫЫ Должен использоваться PerCall, для которого создается новый, отдельный инстанс при вызове без твохи левых ограничений. Если не в танке, то не забивай парню голову всякой хренью

Алексей КSeVaДля вызовов БД это можно сделать.Релиз Entity Framework 6 с поддержкой асинхронностей ещё не вышел. Только бэта пока...

Там, где высокие нагрузки ORM не используют, а в ADO.net это уже есть.

Алексей КSeVaПосему сервисы должны иметь интерфейс с тасками, максимально использовать новый API с asyn\await, которые НЕ СОЗДАЮТ НИКАКИХ ФОНОВЫХ ПОТОКОВ. Для вызовов БД это можно сделать.Теоретически - да. Практически - жили же как-то раньше с синхронной работой воркеров сервера. Асинхронный код писать сложнее. Требует .Net 4.5 Я бы это оставил на крайний случай.

Хреново жили, только серверы плодили