МСУ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 Я бы это оставил на крайний случай.

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

Arm79SeVaТам, где высокие нагрузки ORM не используют, а в ADO.net это уже есть.
+1 с примечанием: я использую BLToolkit, тк по быстродействию уступает нативному коду на пару процентов, не более, зато гораздо удобнее в использовании. Entity Framework или NHibernate на порядок, если не больше, медленнее.

SeVaЗЫЫ Должен использоваться PerCall, для которого создается новый, отдельный инстанс
+1, при условии что у автора WCF. Просто бесконтрольные таски/потоки при большом количестве коннектов сами сожрут кучу ресурсов. WCF поволяет регулировать количество таких потоков.

Когда-то я делал сервис PerSession с моделью подписки и запоминал коллбэки клиентов. Несколько тысяч клиентов держало на раз. Как раз было ожидание ответа со стороны внешних ресурсов.

ИМХО: если ожидания нет, а идут интенсивные расчеты (хотя я пугаюсь от таких расчетов, идущих по 5-10 секунд), то только PerCall.

SeVaновый API с asyn\await, которые НЕ СОЗДАЮТ НИКАКИХ ФОНОВЫХ ПОТОКОВ. Для вызовов БД это можно сделать.
Не работал, не знаю, но мне кажется, что полноценно без фоновых потоков асинхронность не сделать. Я читал вашу эмоциональную дискуссию в другом треде, но не уверен, что вы правы на 100%. Куча примеров с MSDN используют async/await совместно с Task и методами *Async. А для БД я сам делал асинхронное обращение к базе и выдачу результата по коллбэку. Все работало очень шустро.

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