Служба WCF: статус 200 с sc-win32-статусом 64
Мы наблюдали следующее поведение на одном из серверов, обслуживающих службу WCF в IIS 6.0:
- Журнал IIS показывает высокое значение для времени ( > 100000)
- Код состояния HTTP: 200
- sc-win32-status code показывает значение 64
Я узнал, что код sc-win32-status из 64 указывает: "Указанная сеть больше недоступна"
Первоначально я подозревал, что это может быть из-за ограничений, установленных на MinFileBytesPerSecond, который устанавливает минимальную пропускную способность, которую HTTP.sys применяет при отправке данных от клиента к серверу и обратно от сервера к клиенту.
Но значение sc-bytes и cs-bytes указывает, что количество отправленных данных находится в пределах диапазона, обычно наблюдаемого для службы.
Также обратите внимание, что служба WCF размещается в четырех ящиках и сбалансирована по нагрузке, но проблема возникает только с одним из серверов. (но не по существу на том же сервере). Проблема также прерывистая.
Кто-нибудь еще столкнулся с этой ошибкой? Какие-нибудь подсказки о том, что может быть неправильно?
Обновление
Примечание. Наблюдение в IIS 7.5 (версия IIS не имеет большого значения)
Я смог воспроизвести эту проблему. Проблема возникает, если:
1. Служба WCF требует много времени для ответа
2. Прокси-сервер клиента истекает до получения ответа от сервера. В этом случае это приводит к выходу TimeoutException на клиенте.
3. Сервер продолжает ждать TCP ACK для клиента, которого он никогда не получит.
Следовательно, длительный тайм-аут (тайм-аут TCP-сокета (значение по умолчанию: 4 минуты) и sc-win32-статус 64
Таким образом, по сути, кажется, что код WCF требует много времени для ответа, а клиент отключается, то, что я наблюдаю в журнале IIS, является всего лишь симптомом, а не проблемой.
Ответы
Ответ 1
Поведение, которое вы описываете, также будет происходить, если вы превысите максимальные сеансы службы WCF, вызовы или экземпляры (в зависимости от того, как настроен ваш режим конфигурации экземпляра службы). Если вы наблюдаете счетчики производительности System.ServiceModel для одновременных сеансов% max и/или% max одновременных вызовов (опять же в зависимости от контекста вашего экземпляра службы), вы можете увидеть корреляцию с записями журнала IIS.
Обратите внимание, что эти максимумы могут быть настроены в режиме дросселирования службы.
https://msdn.microsoft.com/en-us/library/vstudio/system.servicemodel.description.servicethrottlingbehavior(v=vs.100).aspx
Ответ 2
IIS переводит службы в спящий режим для сохранения ресурсов.
Скопировано отсюда (Служба REST WCF переходит в спящий режим после бездействия)
Пул приложений, в котором размещается ваша служба, определяет свойство Idle Time-out (дополнительные параметры пула приложений в консоли управления IIS), которое по умолчанию составляет 20 минут. Если в течение неактивного периода пул приложений не получен, рабочие процессы, обслуживающие пул, завершаются. После получения нового запроса IIS должен снова запустить процесс, процесс должен загрузить домен приложения и все связанные сборки, скомпилировать файл .svc, запустить хост службы и обработать запрос. Решение может увеличить время простоя, но смысл этого тайм-аута - правильная обработка ресурсов сервера. Если процесс не нужен, его следует остановить. Другой уродливый обходной путь - использование некоторого процесса ping (например, задания cron или запланированной задачи на сервере), который будет регулярно вызывать ping для вызова метода на службе или странице в том же приложении.
Ответ 3
Я снова увидел ваш вопрос и хотел указать, что нашел решение для этого. Это оказалось частью кода в файле web.config:
<pages smartNavigation="true">
После этого вы перестали получать одинаковые ошибки тайм-аута. См. Также ответ здесь