Использует ли WCF ThreadPool для вызова новых экземпляров для службы PerCall?

для службы WCF PerCall, чья настройка была высокой (например, 200 одновременных вызовов), WCF вызовет новый экземпляр и вызовет запрос в потоке threadpool?

Если это так, то это повлияет на общее количество разрешенных одновременных вызовов?

Я спрашиваю, потому что я, кажется, никогда не попадал в максимальное количество одновременных вызовов, которые я установил в конфигурацию дросселирования службы, но вместо этого доля этого числа - до 50 на 100 MaxConcurrentCalls и 160 на 200 MaxConcurrentCalls.

Спасибо,

ОТВЕТЫ

Ответ 1

Похоже, что WCF использует потоки управляемых потоков ввода-вывода из CLR ThreadPool для обслуживания запросов с дополнительным оговоркой, которая использует собственный планировщик потоков.

Из Wenlong Dong Blog - Почему ответы WCF медленно и SetMinThreads не работают?

Прежде всего, WCF использует управляемые потоки ввода-вывода для обработки запросов. CLR ThreadPool сохраняет определенное количество потоков холостого ввода-вывода от уничтожения. Когда требуется больше потоков ввода-вывода, они создаются ThreadPool, что является дорогостоящим.

Из Блог Wenlong Dong: изменение режима дросселирования и масштабирование сервера

В .NET 3.0 и 3.5 существует специальное поведение, которое вы наблюдаете для служб WCF, поддерживаемых IIS. Всякий раз, когда приходит запрос, система будет использовать два потока для обработки запроса: один поток - это поток потока CLR ThreadPool, который является рабочим потоком, который поступает из ASP.NET. Другой поток - это поток ввода-вывода, который управляется WCF IOThreadScheduler (фактически созданный ThreadPool.UnsafeQueueNativeOverlapped).

Существует множество настроек, которые влияют на пропускную способность WCF. Поскольку WCF использует управляемый ThreadPool, настройки ThreadPool MinIOThreads и MaxIOThreads будут влиять на результат. После того, как потоки ввода-вывода (или рабочие потоки, если вы их используете), будут взяты из ThreadPool, ThreadPool будет задерживаться на некоторое время, прежде чем начать новый поток для обслуживания запрошенного запроса. Увеличивая MinIOThreads, вы можете предотвратить эту задержку. Если вы нажмете ограничение MaxIOThread, это наверняка ограничит количество одновременных запросов, которые вы увидите; однако это не похоже на ваш тест 50/100, потому что вашему следующему тесту удалось получить 160 одновременных запросов. Если я правильно помню, я считаю, что используемая вами среда хостинга (IIS, WAS, self) может диктовать некоторые параметры ThreadPool. Кроме того, если вы прочитаете сообщение в блоге со второй ссылки, вы увидите, как рабочие потоки IIS блокируются, когда WCF обрабатывает запрос в отдельном потоке ввода-вывода. Поэтому в этом случае параметры рабочего потока и настройки IIS повлияют на WCF concurrency. Как вы размещаете эту услугу?

В вашем заголовке упоминается экземпляр PerCallContextMode, который сделает ConcurrencyMode неактуальным. Однако с PerCall вам нужно будет знать о настройке MaxConcurrentInstances, а также о MaxConcurrentCalls. В зависимости от вашей привязки вам также может потребоваться свойство MaxConcurrentSessions. Какую привязку вы используете для размещения этой службы?

Независимо от всего вышеизложенного, то, что вызывает недоумение, - это тест 160/200, который следовал вашему тесту 50/100.