WCF 3.5 против 4.0 RESTful производительность услуг - PullRequest
4 голосов
/ 28 мая 2011

У меня есть несколько WCF RESTful-сервисов, которые были разработаны с WCF 3.5 + RESTful Starter Kit.Я сталкивался со многими из тех же самых жалоб, когда он не очень эффективен и не очень хорошо обрабатывает пакет запросов.Я думаю, что одной из причин этого было то, что функции RESTful в 3.5 были скорее надстройкой сообщества.

Теперь, когда сервисы WCF 4.0 RESTful уже давно отсутствуют, я предположил, что есть некоторые люди.которые разработали с ним и используют его в производственной среде.

Я изучал использование шаблона 40 REST службы WCF (CS) и проверял, есть ли у кого-нибудь проблемы с производительностью / масштабируемостью.Я также проверял, было ли проведено сравнение производительности / масштабируемости между WCF 3.5 и WCF 4.0 RESTful-сервисами.Быстрый поиск в Google не дал много результатов.

Любая обратная связь будет принята с благодарностью.

Редактировать

Для запроса здесьмоя конфигурация:

<bindings>
  <webHttpBinding>
    <binding name="TransportWeb">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>
  </webHttpBinding>
</bindings>

<services>
  <service behaviorConfiguration="SecureBehavior" name="Service">
    <endpoint address="" binding="webHttpBinding" bindingConfiguration="TransportWeb" behaviorConfiguration="REST" contract="IServce"/>
    <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange"/>
  </service>
</services>

<behaviors>
  <serviceBehaviors>
    <behavior name="SecureBehavior">
      <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
    </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
    <behavior name="REST">
      <webHttp/>
    </behavior>
  </endpointBehaviors>
</behaviors>

Ответы [ 2 ]

4 голосов
/ 28 мая 2011

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

Итак, вот несколько вопросов о вашей реализации, которые, мы надеемся, могут помочь сообществу помочь вам лучше:

  • Какие запросы вы отправляете?
  • Какие функции стартового комплекта вы используете?
  • Как настроены ваши привязки?
  • Потоковая передача любых двоичных данных?
  • Используете ли вы какие-либо меры безопасности?(SSL, пользователь / пароль и т. Д.)
  • Выполняете ли вы какие-либо длительные задачи для каких-либо запросов?

Обновление 1

Так что все выглядит хорошо с точки зрения привязки, и то, что вы объясняете, звучит так, будто у вас здесь довольно «ванильный» сервис WCF.Это не похоже на то, что вы используете какой-либо из фреймворка для начинающих WCF 3.5 вообще из вашего описания, поэтому я не уверен, что вы упускаете какие-то детали или если вы былипросто ошибаюсь, говоря, что вы используете его.

Одна вещь, которую я заметил, вы не сделали, однако в вашей конфигурации службы были установлены какие-либо явные значения <serviceThrottling>.По умолчанию в .NET 3.5 максимальное количество одновременных вызовов составляет всего 16 .Таким образом, в зависимости от продолжительности ваших звонков и насыщенности в любой момент от ваших клиентов, вы можете быть там задержаны.Если вы ознакомитесь с этим разделом MSDN под названием Оптимизация производительности веб-службы WCF , вы увидите некоторые рекомендации, в которых рекомендуется на самом деле настроить maxConcurrentCalls на 16 для каждого ядра.Это единственное место, где .NET 4 отличается, потому что они фактически делают 16 * число ядер автоматически для вас, если вы не укажете свое собственное явное значение.Естественно, единственный способ найти подходящее место для вашего приложения - это нагрузочное тестирование и игра с числом.

Все это говорит о том, что я не вижу больше неправильной информации, предоставленной вами.Если вы расскажете нам больше о внутренностях вашего веб-сервиса, возможно, мы сможем дать вам несколько лучших рекомендаций о том, как добиться лучшей производительности.Насколько мы знаем, на данный момент ваше узкое место может быть в какой-то базе данных, с которой вы взаимодействуете.

Итак, чтобы ответить на заголовок этого вопроса: На данный момент я не думаю, что вас что-то сдерживает, потому что выИспользуешь 3.5.В 4.0, безусловно, есть некоторые улучшения производительности, но вы не говорите здесь о мегамасштабах или чем-то еще, и, как я уже сказал, вы на самом деле не делаете каких-либо сложных настроек WCF или чего-либо в соответствии с вашим описанием.

2 голосов
/ 28 мая 2011

См. http://blogs.msdn.com/b/endpoint/archive/2011/05/04/wcf-scales-up-slowly-with-bursts-of-work.aspx для получения дополнительной информации о причине и решении этой проблемы.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...