Похоже, что WCF использует потоки управляемого ввода-вывода из CLR ThreadPool для обслуживания запросов с дополнительным предупреждением, которое использует свой собственный планировщик потоков.
Из Блог Вэньлун Донга - Почему ответы WCF медленные и SetMinThreads не работает?
Прежде всего, WCF использует потоки управляемого ввода-вывода для обработки запросов . CLR ThreadPool предотвращает разрушение определенного количества незанятых потоков ввода-вывода. Когда требуется больше потоков ввода / вывода, они создаются ThreadPool, что довольно дорого.
Из Блог Вэньлун Донга: регулирование запросов WCF и масштабируемость сервера
В .NET 3.0 и 3.5 существует особое поведение, которое вы наблюдаете для служб WCF, размещенных на IIS. Всякий раз, когда поступает запрос, система будет использовать два потока для его обработки: один поток - это поток CLR ThreadPool, который является рабочим потоком из ASP.NET. Другой поток - это поток ввода-вывода, которым управляет IOThreadScheduler WCF (фактически созданный ThreadPool.UnsafeQueueNativeOverlapped) .
Существует множество настроек, которые влияют на пропускную способность WCF. Поскольку WCF использует управляемый ThreadPool, настройки MinIOThreads и MaxIOThreads ThreadPool будут влиять на результат. После того, как все незанятые потоки ввода-вывода (или рабочие потоки, если вы их использовали) извлекаются из ThreadPool, ThreadPool будет на некоторое время задерживаться, прежде чем закрутить новый поток для обслуживания запроса в очереди. Увеличив MinIOThreads, вы можете предотвратить эту задержку. Если вы достигнете предела MaxIOThread, это наверняка ограничит количество одновременных запросов, которые вы увидите; однако в вашем тесте 50/100 это не так, потому что при следующем тесте удалось запустить 160 одновременных запросов. Если я правильно помню, я считаю, что используемая вами среда хостинга (IIS, WAS, self) может диктовать некоторые настройки ThreadPool. Кроме того, если вы прочитаете сообщение в блоге по второй ссылке, вы увидите, как рабочие потоки IIS блокируются, когда WCF обрабатывает запрос в отдельном потоке ввода-вывода. Таким образом, в этом случае параметры рабочего потока и параметры IIS будут влиять на параллелизм WCF. Как вы размещаете эту услугу?
В вашем заголовке упоминается PerCall InstanceContextMode, который делает ConcurrencyMode неактуальным. Тем не менее, с PerCall вам нужно знать о параметре MaxConcurrentInstances, а также о MaxConcurrentCalls. В зависимости от вашей привязки вам также может потребоваться свойство MaxConcurrentSessions. Какую привязку вы используете для размещения этого сервиса?
Независимо от всего вышесказанного, то, что вызывает недоумение, это тест 160/200, который последовал за вашим тестом 50/100.