Что может задержать установление новых соединений с NetTcpBinding?

Question

У нас есть служба WCF, а иногда запросы, выполняемые через новые каналы, занимают от 3 до 8 секунд, хотя одновременные запросы, которые используют объединенные каналы, обрабатываются мгновенно. Другими словами, система реагирует в целом.

Число обрабатываемых одновременно запросов составляет менее 10, что намного ниже, чем у любого настроенного верхнего предела, а количество одновременных сеансов также не должно претерпеть каких-либо ограничений. Вот как настроено обслуживание:

NetTcpBinding binding = new NetTcpBinding(SecurityMode.None); 

binding.ReceiveTimeout = TimeSpan.MaxValue; 

binding.ReaderQuotas.MaxArrayLength = int.MaxValue; 
binding.ReaderQuotas.MaxStringContentLength = int.MaxValue; 
binding.ReaderQuotas.MaxDepth = int.MaxValue; 
binding.ReaderQuotas.MaxBytesPerRead = int.MaxValue; 
binding.ReaderQuotas.MaxNameTableCharCount = int.MaxValue; 

binding.MaxReceivedMessageSize = int.MaxValue; 
binding.MaxBufferSize = int.MaxValue; 
binding.MaxBufferPoolSize = int.MaxValue; 
binding.MaxConnections = 256; 

host.AddServiceEndpoint(contract, binding, address); 
host.Description.Behaviors.Remove(typeof(ServiceDebugBehavior)); 
host.Description.Behaviors.Remove(typeof(ServiceMetadataBehavior)); 
host.Description.Behaviors.Remove(typeof(ServiceThrottlingBehavior)); 
host.Description.Behaviors.Add(new ServiceMetadataBehavior { HttpGetEnabled = false }); 
host.Description.Behaviors.Add(new ServiceThrottlingBehavior { MaxConcurrentCalls = 256, MaxConcurrentSessions = 1000, MaxConcurrentInstances = 1000 }); 

host.Open(); 

Любая идея в чем проблема?

Answer 1

Я попытался загрузить систему, аналогичную той, что у нас есть в производстве, и смог установить соединение более чем на 5 секунд, установив около 100 подключений и разрешив каждому из них вызовы WCF, которые только Thread.Sleep(20ms) на сервера, в бесконечном цикле.

Выполнение методов на вновь созданных каналах постепенно увеличивалось дольше 5 секунд, тогда как те же методы, которые выполнялись на существующих каналах, занимали всего до 500 миллисекунд.

Оказалось, что сервер, который имеет 4 центрального процессора ядер, всегда вызывая метод в 1 только от 4 до 7 различных нитей (в подавляющем большинстве случаев в 1 из 4 нитей, но иногда 3 другие потоки привыкли, а). Это не дает вам много параллелизма, что особенно полезно, если эти методы ждут в IO (как имитируется вызовом Sleep()).

Я пробовал ThreadPool.SetMinThreads(40, 40), но это не помогло, я думаю, из-за bug in .net 3.5.

So Я пробовал .net 4, и даже без вызова SetMinThreads проблемы исчезли. Я заметил, что метод на сервере вызывается из многих других потоков в настоящее время, а количество фактически используемых потоков ввода-вывода ввода-вывода растет и по мере необходимости.

N.B. На самом деле, есть что-то похожее на это в базе знаний MS»: WCF service may scale up slowly under load Она представляет собой обходной путь, чтобы сделать WCF выполнять на рабочих потоков вместо IO потоков, которые, в соответствии с этой статьей, могут войти

состояние, в котором он не может создавать потоки достаточно быстро, чтобы немедленно обрабатывать пакет запросов. Время отклика неожиданно увеличивается при создании новых потоков со скоростью 1 на 500 мс.

Это плохо, в моем случае, однако, новые нити IO не были созданы вообще, по крайней мере, не в десятки секунд моих тестов.