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