Нужно ли перезаписывать тайм-ауты WCF / IIS? - PullRequest
1 голос
/ 04 марта 2010

В последнее время я много работаю на фронте WCF и специально хостинг в IIS (не сам хостинг).

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

Посмотрите на следующие значения конечной точки привязки, которые так или иначе связаны с тайм-аутом:

  • closeTimeout = "00:01:00"
  • openTimeout = "00:01:00"
  • ReceiveTimeout = "00:10:00"
  • SendTimeout = "00:01:00"
  • MaxBufferSize = "999"
  • maxBufferPoolSize = "524288"
  • MaxReceivedMessageSize = "999"
  • readerQuotas maxDepth = "32"
  • readerQuotas maxStringContentLength = "8192"
  • readerQuotas maxArrayLength = "16384"
  • readerQuotas maxBytesPerRead = "4096"
  • readerQuotas maxNameTableCharCount = "16384"

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

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

IIS требует отключения поддержки активности, пул приложений также включает в себя широкий спектр значений тайм-аута, пул приложений, это отдельный подробный предмет. Помимо этого есть еще около 7 значений тайм-аута, которые должны быть точно настроены, иначе ожидайте, что ваши сложные вызовы WCF потерпят неудачу.

Простите, а кто-нибудь еще пахнет крысой?

Насколько я понимаю, по существу (большинство) этих значений времени ожидания существуют из-за проблем доверия. Под доверием я подразумеваю: «Мы не доверяем службам, которые делают то, что должны делать в разумные сроки». Каждый аспект надежной связи SOA не доверяется сразу, и поэтому кажется, что для обеспечения некоторой степени управляемости нам нужны огромные массивы сетей уловов (значений времени ожидания). Посмотрим правде в глаза: если мы доверяем системам для своевременного предоставления ответа, зачем нужно устанавливать значение тайм-аута?

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

Я заметил, что технология WCF лицемерна, во время веб-трансляций и маркетинговых презентаций, как правило, всегда упоминается, что WCF позволяет лучше абстрагироваться от реализации, что позволяет разработчикам легче писать и развертывать, а "просто" определять конечные точки возможность сконцентрироваться на бизнес-логике, и меньше на подчеркивающей архитектуре. Я обнаружил на практике, что ничто не может быть дальше от истины. С WCF вам нужно глубоко вникнуть в детали того, как работает ваш сервис, и вам нужно много точно настроить вручную, в отличие от сервисов ASMX, где они обычно развертываются без особых хлопот и нуждаются только в некоторой тонкой настройке IIS, редко даже.

Итак, я задаю вопрос: это только у меня или у кого-то из вас одни и те же разочарования и наблюдения? Все комментарии приветствуются!

1 Ответ

2 голосов
/ 04 июня 2010

С чего начать?

Необходимо помнить, что службы WCF спроектированы так, чтобы быть независимыми от хост-приложения. Службы WCF можно размещать в приложениях командной строки, приложениях WinForms, службах Windows, IIS, Silverlight, приложениях Win32, приложениях MFC и т. Д. В соответствии с вашими сценариями и потребностями.

Таким образом, инфраструктуру WCF и инфраструктуру хост-приложений необходимо независимо контролировать и настраивать.

В вашем случае вы решили разместить свои службы WCF в IIS. Это хороший выбор для широкого спектра сценариев, но плохой выбор в других. Зачем? Потому что IIS специально создан для очень целевого сценария: получение и отправка запросов недолговечным рабочим процессам и возврат ответов вызывающей стороне.

Это «недолгое» утверждение было преднамеренным: IIS в основном используется в качестве веб-сервера. По умолчанию он настроен на работу в качестве веб-сервера. Веб-серверы обычно настроены так, чтобы отвечать на звонки как можно быстрее. Веб-сервер не знает, является ли рабочий процесс, порожденный запросом страницы, "занятым" или "зависшим", если рабочий процесс не возвращает ответ. Пока ответ не получен, веб-сервер может только предполагать, что рабочий процесс "занят". Если рабочий процесс не ответил в течение заданного (настраиваемого) периода времени, веб-сервер принимает решение прекратить рабочий процесс, так как он, вероятно, завис.

Итак, в вашем сценарии вы используете IIS для размещения нетипичного приложения, которое предъявляет особые требования (то есть возможность выполнять длительные операции). Если вы, разработчик / администратор приложения, знаете, что некоторые приложения могут не возвращаться более 10 минут, вы можете установить время ожидания для рабочего процесса, в котором размещается ваше приложение особого случая. Это хорошая вещь. Если бы вам не дали эту возможность, вы бы закричали, когда ошибка в вашем коде или замедление на уровне вашей БД поставили на колени весь веб-сервер, убив каждый веб-сайт, размещенный на этой машине, потому что ни один из ваших рабочих процессов тайм-аут.

Примерно такая же логика применима к настройкам конфигурации WCF:

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

Если, как вы указали, у вас есть службы WCF, которые выполняют долгосрочные задачи, вы можете выбрать НЕ размещать их в IIS и размещать в приложении службы Windows. В этом случае ваше хостинговое приложение будет мало чем отличаться от размещения ваших служб и вместо этого соответствующим образом реагирует на уведомления о запуске и завершении работы. Итак, как бы вы контролировали способность ваших сервисов обрабатывать сообщения с ОЧЕНЬ большими нагрузками? Как бы вы контролировали количество одновременно создаваемых экземпляров сервисов? Как бы вы контролировали, как долго WCF ожидает открытия и / или закрытия нового экземпляра службы?

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

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