WCF время отклика, дросселировании

Question

Моей конфигурации WCF службы:

<system.net> 
    <connectionManagement> 
     <add address ="*" maxconnection="500"/> 
    </connectionManagement> 
</system.net> 

<bindings> 
    <basicHttpBinding> 
    <binding name="customBasicHttpBinding" 
     maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" 
     transferMode="StreamedResponse"> 
     <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
       maxArrayLength="2147483647" maxBytesPerRead="2147483647" 
       maxNameTableCharCount="2147483647"/> 
     <security mode="None"/> 
    </binding> 
    </basicHttpBinding> 
    <webHttpBinding> 
    <binding name="customWebBinding" maxBufferSize="2147483647" 
     maxReceivedMessageSize="2147483647"> 
     <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
      maxArrayLength="2147483647" maxBytesPerRead="2147483647" 
      maxNameTableCharCount="2147483647"/> 
     <security mode="None"> 
     </security> 
    </binding> 
    </webHttpBinding> 
</bindings> 

<serviceBehaviors> 
    <behavior name="soapBehavior"> 
     <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> 
     <dataContractSerializer maxItemsInObjectGraph="6553600"/> 
     <serviceDebug includeExceptionDetailInFaults="false"/> 
     <serviceThrottling maxConcurrentCalls="100" 
      maxConcurrentInstances="100" maxConcurrentSessions="100" /> 
    </behavior> 
</serviceBehaviors> 

<services> 
    <service behaviorConfiguration="soapBehavior" name="Service.Service"> 
     <endpoint name="soap" 
      address="" 
      binding="basicHttpBinding" bindingConfiguration="customBasicHttpBinding" 
      contract="ServiceModel.IService"/> 
     <endpoint 
      address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> 
    </service> 
</services> 

Как вы можете видеть, что я настроить дросселирование параметра для обработки 100 одновременных экземпляров.

Для целей тестирования я создал фиктивный метод на мой интерфейс, который выглядит примерно так

[OperationContract] 
string Test(){ 
    return "test response time"; 
} 

Когда я пытаюсь вызвать этот метод, он использует 100 параллельный запрос ATS когда время отклика очень плохо:

Сейчас работает 100 параллельных запросов ...
: 0,45205P временем реакции, 10,047P, 0,43304P, 0,86609P, 1,33913P, 0,91409P, 1,34713P, 1,75718P, 1 , 37414P, 1,80718P, 1,80618P, 2,22622P, 2,64426P, 2,22822P, 2,62626P, 2,68127P, 3,0453P, 3,10731P, 3,47 635P, 3,51035P, 3,91039P, 3,94039P, 3,9544P, 4,36844P, 4,34943P, 4,78748P, 4,37144P, 4,82248P, 4,79048P, 5,25052P, 4,81948P, 5,67657P, 5,25253P, 5,71657P, 5,67357P, 6,13761P, 5,70257P, 6,56566P, 6,12361P, 7,0117P, 6,53065P, 7,43674P, 6,9517P, 7, 86679P, 7,36974P, 7,81778P, 8,29483P, 8,75988P, 8,71587P, 8,24182P, 8,70187P, 9,16392P, 9,12991P, 9,19492P, 9,57596P, 9,65797P, 10 08201P, 10,45205P, 10,52505P, 10,48905P, 10,9521P, 10,89709P, 11,37714P, 11,81118P, 11,32413P, 11,76418P, 11,83918P, 12,18222P, 12, 31723P, 12,60526P, 12,75128P, 13,0423P, 13,17132P, 13,48935P, 13,64836P, 13,91039P, 14,07141P, 14,32843P, 14,48945P, 14,78548P, 14,91149P, 15,20652P, 15,33153P, 15,62856P, 15,75558P, 16,0516P, 16,19262P, 16,48265P, 16,61866P, 16,91169P, 17,05471P, 17,33773P, 17,48375P, 17, 74677P, 17,92079P, 18,15782P, 18,34183P, 18,58086P, 18,77388P, 19,0069P,
0 запросов (ов) не удалось.
Среднее время отклика: 9,20126

Почему результаты настолько плохо, я пытался изменить AppPool Worker количество процессов, но не повезло, кто может сказать, что я пропускаю, что устанавливает ограничения?

Я использую WCF 4.0, IIS7.5 на машине Windows Server 2008R2.

Спасибо

Answer 1

трудно обеспечить намного больше информации о проблемах с производительностью связи без получения подробной информации о сервисе, конфигурации и окружающей среде. По крайней мере, вы можете предоставить привязку к сервису, атрибут ServiceBehaviorAttribute и информацию о конфигурации клиента.

С годами проведения тестирования и оптимизации производительности WCF мы видели «похожие» проблемы, как вы описали ... несмотря на наличие 100 одновременных подключений, служба, похоже, не «эффективно реагирует», хотя серверные ресурсы не выглядят занятый. В нашем случае «задержка» была связана с медленным «холодным» запуском и временем, затраченным пулом потоков .NET для распределения потоков.

Следующая статья обсуждает наш вопрос:
http://blogs.msdn.com/b/dmetzgar/archive/2011/05/04/wcf-scales-up-slowly-with-bursts-of-work.aspx

удачи.

Answer 2

Я только что закончил крупный промышленный проект WCF, который использовал дросселирование и обнаружил, что дросселирование не всегда дает ожидаемые результаты. Мы создали веб-службу WCF на виртуальном сервере производственного класса, затем мы создали тестовый жгут, который эмулировал 1000+ виртуальных клиентов в многопоточной программе.Как только мы были готовы, мы снова и снова запускали тесты снова и снова, используя множество различных настроек дросселирования от 1 до 1000, но были удивлены результатами.

Например, можно подумать, что запуск веб-службы с 200 Максимальное количество одновременных соединений будет в два раза быстрее, как 100 макс соединений, но это не то, что мы нашли для настройки для таких вещей, как:

-max одновременно сессий

-Max одновременных вызовов

-Max параллельных экземпляров

на самом деле, не было большого спектакля (callsProcessed/вторая) разница между MaxConcurrentSessions = 10 и MaxConcurrentSessions = 1000. Обработанные в секунду вызовы были примерно одинаковыми, только использование памяти было иным. То же самое с другими настройками дроссельной заслонки.

Самая быстрая установка, которую мы нашли для дросселирования? Нет настройки вообще; в основном, пусть библиотека System.ServiceModel обрабатывает все. Это самое быстрое, что мы обнаружили после нескольких дней тестирования.

Что касается вашего выступления, то я бы попытался выяснить, где находятся шеи бутылки. Например, если ваша служба WCF использует SQL для извлечения данных, попробуйте исключить SQL и просто вернуть статический набор данных и посмотреть, будет ли ваше время значительно улучшаться. Если да, то, возможно, вам нужно работать с базой данных. Если это не так, может быть проблема с обработкой ваших SOAP-сообщений.