Через Remoting (WCF) на сервере запускается всего несколько потоков, независимо от размера тредпула и заданного количества параллельно обрабатываемых коннекшенов. Кроме Remoting ThreadPool никто не использует. Увеличение BacklogLimit (или как там они его называют?) просто отдаляет смерть.

Количество коннекшенов вообще непонятная цифирь, разве что MS для Remoting использует fibers (несколько физических потоков обрабатывают большую пачку пользовательских потоков).

Но MS отказалась от повсеместного внедрения fibers, кроме SQL Serever 2005.

Нашёл пока только у MS рекомендацию хостить Remoting-сервисы через IIS, якобы там управление ресурсами гораздо круче, да ещё и GC какой-то убермощный используется.

Вопрос, собственно, в увеличении количества потоков для Remoting.
Пока писал, пришла идея увеличить максимальный размер ThreadPool. Но думается, что поможет это как мёртвому припарка...

Может, есть решения по отпусканию Remoting-потока, чтобы можно было сделать что-нибудь длинное и потом вернуть его себе и отдать клиенту результат?

guest00x Иванов АндрейЧерез Remoting (WCF) ...
Remoting <> WCF, как минимум, "формально", т.е. "по доке", внутри наблюдаются те же прокси и т.п., но, как я понял, Remoting !=(строго не равен) WCF.
Так с чем у Ва проблемы - с Remoting или с WCF ?

Проблемы с WCF.
Но я уверен, что с Remoting будут те же проблемы. Может быть, числа будут разные, сути это не меняет - при наличии свободных 1000 потоков всего 10 (когда-то давно для Remoting цифра была ~20 одновременно обрабатываемых запросов, сколько физических потоков, не посмотрели) выделяется для WCF/Remoting.

Я, естественно, попробую увеличить размер ThreadPool, но даже если это поможет, решение не очень красивое получается.

студент_спбГУИванов Андрей, Вопрос не в тему, но вы случайно, не преподавали в этом году в СПбГУ?
Нет, я никогда не преподавал и в Питере ни разу не был.
Но побывать хочется =)

LRМожет помогут настройки ServiceThrottlingBehavior?
Не помогают. Тестировали на Professional и WS2003.

LRКак вариант, можно организовать("вручную") выполнение любого удаленного метода в своем(новом) треде. Стоимость "увода" в новый тред относительно незначительна...
А это как? Я предполагал, что такое может быть, но чуть не сломал голову с ExecutionContext.
Быстро с ним разобраться не получилось, если нет прямых ссылок, посоветуйте, куда копать надо, чтобы выполнение уводилось в мой тред.

Ещё есть вариант заморочиться со своим каналом или одной из его частей, но это не лучше, на мой взгляд, чем хоститься в IIS.

LRМожет помогут настройки ServiceThrottlingBehavior?
Пример в MSDN неправильный был.
В Гугле встретился тоже неправильный =)
Решили сделать немного иначе и всё заработало.

LRМожет помогут настройки ServiceThrottlingBehavior?

Как вариант, можно организовать("вручную") выполнение любого удаленного метода в своем(новом) треде. Стоимость "увода" в новый тред относительно незначительна...
Спасибо за совет про Remoting.
Но про треды всё равно интересно, можете подсказать?

LR Иванов АндрейНо про треды всё равно интересно, можете подсказать?
в двух словах :)
в FW 2.0 появился ParameterizedThreadStart, значит, в тред можно передать завернутую в параметр всю необх.инфу, ну и вернуть результат (типа object)

в static ("утилитного" класса, доступного отовсюду) методе:
new Thread(ParameterizedThreadStart)
newThread.Start(параметр)
newThread.Join()
return параметр.результат

в private static методе ParameterizedThreadStart:
параметр.результат = параметр.obj.type.InvokeMember(параметр.название_метода, BindingFlags.InvokeMethod, ..., параметр.target, параметр.args)
Дык, это получится, что поток, созданный в Remoting, будет спать, пока не отработает мой новый поток.
То есть, увода никакого не получается.
Я думал, что можно выполнение Remoting-потока перенаправить в другой поток, а Remoting-поток вернуть обратно в пул.

LRКстати, "Решили сделать немного иначе и всё заработало." - в двух словах, в чем была проблема, мож тож на те же грабли наступать придется? :)
Секция в сэмплах стоит не та, которая надо.