Назад | Перейти на главную страницу

Как запретить IIS перезапускать пул приложений, когда рабочий процесс не отвечает

У нас есть служба WCF, которая обрабатывает большое количество запросов.

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

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

Независимо от причины тайм-аута и длительного времени отклика в коде (над которым мы уже работаем) мой вопрос таков:

Если мы определим более одного рабочего процесса для этого пула приложений, что произойдет, если один из рабочих процессов окажется в такой же ситуации? Перерабатывает ли IIS пул приложений или конкретный рабочий процесс будет убит, а другие будут продолжать обслуживать запросы?

Если вам действительно действительно нужно, чтобы рабочий процесс боролся с этим, вы можете отключить функцию Ping в свойствах Advanced App Pool, как я предполагаю, IIS обнаруживает, что пул приложений перестает отвечать.

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

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

По другому вопросу / альтернативе выше: если ваше приложение не имеет состояния и поддерживает мультиэкземплярность в веб-саду (MaxProcesses> 1), тогда IIS перезапустит рабочий процесс, который стал неотзывчивым, а не все WP, принадлежащие пулу приложений. - поищите журналы системных событий, идентифицирующие PID, который используется повторно.