Чек-ап веб-публикации на IIS: вердикт по каждой настройке

Веб-публикация работает "как-то": сервисы иногда перестают отвечать, изредка прилетает 500, после простоя первый вход тянется полминуты, а лицензии кончаются раньше, чем должны по расчёту. Обработка проверяет публикацию по списку и по каждому пункту говорит не что там написано, а чем текущее значение кончится.

Что она снимает со стороны 1С

Первая кнопка, доступ к веб-серверу не нужен. Обработка находит файлы публикаций на машине, подставляет ту, что относится к текущей базе, разбирает её и показывает:

• пул соединений публикации: есть ли элемент pool, какой у него size и что означают его таймауты в человеческих единицах, а не в исходных числах;
• пул сеансов по каждой точке - веб-сервисы, HTTP-сервисы, OData, аналитика: reuseSessions, sessionMaxAge, poolSize, poolTimeout;
• сколько точек опубликовано и сколько из них включено;
• режим отладки в боевом файле публикации;
• пароль в строке соединения, если он лежит в файле открытым;
• живые сеансы базы и отдельно те, что пришли через публикацию.

Время жизни сеанса считается по удвоенному номиналу. Это не осторожность, а замер: при sessionMaxAge="20" лишние сеансы жили 40-45 секунд, воспроизведено двумя прогонами с разным шагом наблюдения. Расчёт лицензий по номиналу ошибается вдвое.

Что она снимает со стороны веб-сервера

К конфигурации IIS обработка не подключается: изнутри 1С её не видно, а модуль администрирования требует прав. Вместо этого она печатает готовый PowerShell-скрипт, его запускает администратор, а результат вставляется обратно и разбирается.

В настройках IIS скрипт ничего не меняет. Только читает. Ни одного изменяющего вызова в нём нет.

Скрипт собирает: пул приложений публикации и его Idle Time-out, разрядность пула, время старта рабочего процесса, обработчик и его модуль, ISAPI-ограничения, права на каталог публикации и web.config, разбивку 5xx и 401 из логов по подкодам, список версий платформы в каталоге.

Результат он не выводит в консоль, откуда его неудобно копировать. По окончании скрипт кладёт текст в файл рядом с собой, копирует его в буфер обмена и открывает в блокноте. В обработке текст либо вставляется в поле, либо берётся кнопкой прямо из файла.

Проверка, которой нет в других инструментах

Настройки публикации перечитываются только при старте рабочего процесса: пока он живёт, файл на диске он не смотрит. Значит существует целый класс публикаций, где строку дописали, а пул не перезапускали - и настройка лежит неприменённой.

Обработка сравнивает дату изменения файла публикации с временем старта рабочего процесса. Файл новее - вердикт "правка не применена". Ни одна сторона не может ответить на это сама: изнутри 1С видна дата файла, со стороны веб-сервера - время процесса.

Расшифровка кодов отказа

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

• 401.5 читают как "IIS не пускает" и чинят аутентификацию. Подкод 5 означает отказ самого расширения ISAPI, то есть 1С;
• 500.0 чаще всего разрядность пула против разрядности модуля, права на web.config и запрет обработчика в ISAPI-ограничениях;
• 502 рядом с 1С списывают на "сервер отвалился", а он может означать исчерпанный пул соединений: запрос не дождался свободного слота. Померено;
• 503 - другая очередь, очередь пула приложений, а не пула соединений публикации.

Порядок работы

1. Открыть обработку в опубликованной базе. Публикация текущей базы подставляется сама, остальные - по кнопке.
2. Нажать "Проверить публикацию". Половина проверок отработает сразу.
3. Вкладка "Сторона веб-сервера", кнопка "Собрать скрипт", затем "Сохранить скрипт в файл".
4. Запустить скрипт на веб-сервере в PowerShell от имени администратора.
5. Вставить результат в поле или взять файл кнопкой, нажать "Разобрать ответ".

Ограничения, названные прямо

• Без прав администратора скрипт вернёт пустые значения, а не ошибку. Это поведение модуля администрирования IIS, и оно проверено запуском. Поэтому скрипт сообщает первой строкой, запущен он с правами или нет, а обработка отказывается принимать ответ без прав: пустота, принятая за ответ, хуже отсутствия ответа.
• Пока скрипт не запускали, соответствующие проверки дают "нет данных", а не молчаливые прочерки. Половина диагностики живёт в настройках веб-сервера, и делать вид, что её нет, инструмент не будет.
• Обработка смотрит с той машины, где работает сервер 1С. Если веб-сервер стоит отдельно, путь к файлу публикации указывается сетевым.
• Это инструмент для уже работающей публикации. Первичную настройку он не заменяет.

Требования

Платформа 8.3.10 и выше, управляемые формы. Конфигурация любая, от неё обработка не зависит. Для стороны веб-сервера - PowerShell 5.1 и права администратора на машине с IIS.

Частые вопросы

Она что-то меняет в моей публикации? Нет. Ни в файле публикации, ни в настройках IIS, ни в базе. Только чтение и печать скрипта.

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

У меня Apache, а не IIS. Разбор файла публикации и все проверки со стороны 1С работают одинаково. Скрипт для веб-сервера написан под IIS, для Apache его половина неприменима.

Можно запускать на боевой? Да, обработка только читает. Единственное, что стоит держать в голове: снимок живых сеансов берётся на момент нажатия, под нагрузкой число будет выше.