WCF замедляется с несколькими запросами

Question

WCF замедляется с несколькими запросами

1

У меня есть служба WCF, использующая basicHttpBinding с режимом безопасности TransportWithMessageCredential. Я изучаю вопрос о тайм-аутах, которые получают некоторые наши клиенты. Я написал небольшое тестовое приложение, которое создает несколько потоков на клиенте и делает "простой" вызов на сервер, который не делает ничего, кроме Thread.Sleep течение определенного периода времени.

Когда я запускаю это тестовое приложение, он создает 10 потоков, создает объект с помощью удаленного метода, а затем вызывает его (сообщая ему спать в течение 5 секунд (5000 мс)).

Я также пробовал с несколькими вариантами количества потоков и "сна" времени на сервере, и я обнаружил, что первые 3 или 4 возвращения в течение определенного количества времени, но последующие из них занимают больше времени.

1:12:13.197 Starting Test - Multi1 1:12:13.199 Starting Test - Multi2 1:12:13.203 Starting Test - Multi3 1:12:13.228 Starting Test - Multi4 1:12:13.367 Got connection object - Multi3 1:12:13.368 Starting Test - Multi5 1:12:13.368 Got connection object - Multi1 1:12:13.369 Got connection object - Multi4 1:12:13.369 Got connection object - Multi2 1:12:13.391 Starting Test - Multi6 1:12:13.394 Starting Test - Multi7 1:12:13.398 Starting Test - Multi8 1:12:13.531 Got connection object - Multi5 1:12:13.532 Starting Test - Multi9 1:12:13.533 Got connection object - Multi7 1:12:13.535 Got connection object - Multi6 1:12:13.539 Starting Test - Multi10 1:12:13.565 Got connection object - Multi8 1:12:13.687 Got connection object - Multi9 1:12:13.691 Got connection object - Multi10 1:12:18.396 Ended Test - Multi3 1:12:18.396 Ended Test - Multi4 1:12:18.844 Ended Test - Multi2 1:12:19.345 Ended Test - Multi1 1:12:19.844 Ended Test - Multi5 1:12:20.344 Ended Test - Multi7 1:12:20.844 Ended Test - Multi6 1:12:21.349 Ended Test - Multi8 1:12:21.844 Ended Test - Multi9 1:12:22.344 Ended Test - Multi10

Итак, на основе приведенных выше результатов вы можете увидеть, что все потоки созданы и получен "объект подключения". Это занимает около 500 мс, что не так уж плохо, учитывая то, что он делает.

Затем проверьте Multi3 и Multi4 закончить в около 5000 мс (точно так, как и ожидалось), но к тому времени, 8, 9 и 10 - звонки возвращаются, они берут около 8000-9000ms.

Когда я отслеживаю это на сервере, каждый поток уникален и имеет другой threadId, поэтому он не сражается с пулом потоков.

У меня есть настройка дросселирования, равная 50 для всех свойств.

<serviceThrottling maxConcurrentCalls="50" maxConcurrentInstances="50" maxConcurrentSessions="50"/>

Поэтому не вижу, что это может вызвать задержку.

Rich S 20 май 2014, в 18:10

Источник

Теги:

c#

multithreading

wcf

1 ответ

Ещё вопросы

Seymour · Answer 1 · 2014-05-20T18-54-00.000Z

Возможно, вам потребуется проверить, а затем, возможно, установить минимальное количество потоков, используя метод ThreadPool.GetMinThreads и ThreadPool.SetMinThreads.

Следующий пост, хотя и немного старый, помог нашей команде и может предоставить вам ценную информацию.
http://blogs.msdn.com/b/wenlong/archive/2010/02/11/why-are-wcf-responses-slow-and-setminthreads-does-not-work.aspx

Для справки:
Прежде всего, WCF использует управляемые потоки ввода-вывода для обработки запросов. CLR ThreadPool сохраняет определенное количество потоков холостого ввода-вывода от уничтожения. Когда требуется больше потоков ввода-вывода, они создаются ThreadPool, что является довольно дорогостоящим. Количество простаивающих потоков определяется настройкой "MinIOThreads". Вы можете использовать API ThreadPool.GetMinThreads(), чтобы проверить, какие настройки у вас есть для вашего приложения. По умолчанию в автономном приложении этот параметр представляет собой количество процессоров, которые у вас есть на машине. Например, на моем ноутбуке с 2-ядерными настройками этот параметр равен 2. Из-за этого вы хотели бы увеличить этот параметр MinIOThreads с помощью ThreadPool.SetMinThreads()