Обработка на Инфостарте
Веб-сервисы 1С встают, а кластер здоров
Очередь, в которой ждут вызовы, стоит до сервера 1С. Поэтому изнутри её не видно: в журнале регистрации чисто, метрики кластера в норме, а сервисы не отвечают.
Обработка платная, 10 SM. Если нужен разбор вашей публикации целиком, а не инструмент в руки, напишите нам: схему смотрим за день.
Картина знакомая: интеграция отваливается по таймауту, партнёр жалуется на пятисотые ошибки, вы открываете журнал регистрации и не находите ничего. Это не значит, что всё хорошо. Это значит, что до 1С вызовы не дошли.
Между вызывающей системой и вашей базой стоит веб-сервер и файл публикации. У них свои пулы, свои таймауты и своё представление о том, сколько живёт сеанс. Настроены они обычно один раз при внедрении и с тех пор никем не читались.
Обработка разбирает обе стороны: файл публикации она читает сама, а по настройкам IIS печатает готовый скрипт для администратора и разбирает его вывод. В самом IIS не меняется ничего, скрипт только читает.
Что она показывает
Пул соединений и пул сеансов
Размер пула, таймауты и что они означают в человеческих единицах, а не в исходных числах. Отдельно по каждой точке: веб-сервисы, HTTP-сервисы, OData, аналитика.
Сколько вызовов пройдёт одной волной
Главный практический вопрос при интеграции. Ширину волны задаёт размер пула в файле публикации: на стенде таймауты на неё не влияли.
Настройка, которая лежит неприменённой
Файл публикации перечитывается только при старте рабочего процесса. Пока процесс живёт, диск он не смотрит. Поэтому бывают публикации, где строку в файл дописали, а процесс не перезапускали, и правка не действует.
Режим отладки и пароль в открытом виде
Две вещи, которые остаются в боевом файле после внедрения чаще, чем хотелось бы.
Живые сеансы и те, что пришли через публикацию
Разделение важно при расчёте лицензий: сеансы веб-сервисов ведут себя не так, как пользовательские.
Замер: что задаёт ширину очереди
Стенд: IIS 10.0 и сервер 1С на одной машине, платформа 8.3.27.1606, вся нагрузка шла в один HTTP-сервис. В обоих прогонах все 12 вызовов вернули 200. Два вопроса замер не разводит: действует порог на сервис или на всю публикацию и откуда берётся десятка, когда элемента pool нет.
| Что в default.vrd | Как прошли 12 вызовов по 8 секунд | Весь прогон |
|---|---|---|
| Элемента pool нет, у точек poolSize 10 от конфигуратора | 10 вызовов одной волной, около 8,2 с; 2 ждали вторую волну и заняли около 16,2 с | 16,3 с |
| Дописан <pool size="3"/>, у точек по-прежнему poolSize 10 | 4 волны по 3 вызова, длительность по волнам около 8,7, 16,7, 24,8 и 32,7 с | 32,8 с |
Настройки пула: что проверено замером
В default.vrd настройки пула живут на двух уровнях. Элемент pool записывается на уровне публикации, отдельно от точек, и конфигуратор его не создаёт: строку дописывают руками. Атрибуты reuseSessions, sessionMaxAge, poolSize и poolTimeout есть у каждой точки, их конфигуратор проставляет при публикации сам.
| Настройка | Что показал стенд |
|---|---|
| size в элементе pool | Задаёт ширину волны. Проверено отдельным прогоном: при size 3 двенадцать вызовов пошли по три, хотя poolSize у точек остался 10. |
| attemptTimeout и waitTimeout | Заданы в секундах. Тест шёл при size 1, то есть на одном соединении: длинный вызов на 30 с, через 3 с второй, короткий. При значениях 2 и 2 короткий через 2,05 с получил 502 Bad Gateway, при 1000 и 3000 простоял 27,84 с и дождался ответа. Какой из двух атрибутов обрывает ожидание, неизвестно: значения меняли парой. |
| attempts, serverPingTimeout, serverPingPeriod | Не проверялись. Перевод их значений в минуты и часы держится только на аналогии с двумя соседними таймаутами. |
| Правка default.vrd | Вступает в силу только после перезапуска. При том же size 1 короткий вызов до перезапуска прошёл за 0,10 с, будто ограничения нет, а после простоял в очереди 27,84 с. Это тот же прогон, что строкой выше, и перезапускали в нём весь веб-сервер. В замере с size 3 правка заработала после перезапуска одного пула приложений. |
| sessionMaxAge у точки | Номинал 20 с. Лишние сеансы пропадали между 40-й и 50-й секундой простоя при шаге наблюдения 10 с и между 40-й и 45-й при шаге 5 с. Считается именно простой: сеанс, к которому обращались раз в 5 с, прожил все 107 с наблюдения, дольше мы не смотрели. |
Что обработка скажет про такие настройки
Строки собраны из разных случаев, это не отчёт по одной базе. Таймаут взят из боевой настройки, которой снимали зависание сервисов: size 10000, attemptTimeout 1000, waitTimeout 500, serverPingTimeout 15000. Публикацию без элемента pool и время жизни сеанса мерили на стенде.
| Показатель | Значение | Как надо | Вердикт | Что это значит |
|---|---|---|---|---|
| Элемент pool в default.vrd | нет | есть, size под реальную одновременность | внимание | на стенде публикация без него пропускала десять одновременных вызовов на сервис, одиннадцатый и двенадцатый ждали второй волны без всякой ошибки |
| attemptTimeout в элементе pool | 1000, это 16 мин 40 с | до 600 с, порог обработки | внимание | единица - секунды, значит ожидание почти без конца, и зависший вызов держит слот пула, пока процесс не перезапустят |
| Дата default.vrd против старта w3wp | файл новее процесса | процесс запущен после последней правки | чинить | правка лежит на диске, а публикация живёт по старой копии настроек, пока рабочий процесс не перезапустят |
| sessionMaxAge в файле публикации | 20 секунд | столько, сколько указано | инфо | номинальное значение, на которое все ориентируются |
| Сколько сеанс жил на самом деле | 40-45 секунд | 20 секунд по номиналу | внимание | вдвое дольше номинала, повторилось в обоих прогонах |
Разбор результата
В боевой настройке зависание снял size 10000: с таким размером пул перестал ограничивать вызовы, и очередь пропала. Таймауты там ни при чём: единица у них секунды, attemptTimeout 1000 это 16 мин 40 с ожидания, waitTimeout 500 это 8 мин 20 с. Если на вызов пришёл 502, сначала выясните, кто вернул код. Веб-сервер отдаёт 502 и тогда, когда сервер 1С жив, а вызов не дождался свободного соединения из пула. Автоматический повтор на такой ответ встаёт в хвост той же очереди и удлиняет её. У 401.5 своя ловушка: подкод 5 означает, что отказало расширение ISAPI, то есть сторона 1С, и начинать с аутентификации IIS значит искать не там. Сеансы и лицензии считайте по удвоенному номиналу sessionMaxAge, помня, что замерено одно значение, 20 секунд.
Как это выглядит в работе
- 01
Первая кнопка: доступ к веб-серверу не нужен
Обработка сама находит файлы публикаций на машине, подставляет тот, что относится к текущей базе, и разбирает его.
- 02
Вторая кнопка: скрипт для администратора
Обработка печатает готовый PowerShell-скрипт. Администратор запускает его на веб-сервере, скрипт кладёт результат в файл, копирует в буфер и открывает в блокноте.
- 03
Вставить результат и прочитать вердикты
Текст вставляется в поле обработки или берётся кнопкой прямо из файла, разбор идёт автоматически. По каждому пункту сказано не только текущее значение, но и чем оно кончится под нагрузкой.
- 04
Сверить дату файла и старт процесса
Дата изменения default.vrd есть в свойствах файла, время старта процесса покажет PowerShell, запущенный от имени администратора: Get-Process w3wp | Select-Object Id, StartTime. Если процессов несколько, нужен тот, что обслуживает пул публикации. Файл изменён позже старта процесса - правка ещё не действует. Без прав ни эта команда, ни модуль администрирования IIS ошибки не выдают: StartTime и настройки приходят пустыми.
Не получается самим? Напишите, разберёмся
Связываем 1С с чем угодно: другими базами 1С, сайтами, CRM, банками, госсистемами. Чиним обмены, которые "отваливаются" и копят очереди.
- Стоимость
- 450 000 - 600 000 ₸ТЗ и диагностика, без налогов; типовая задача закрывается в тот же срок, подсистема "ОбменПоHTTP" под ключ - по смете единым счётом
Разборы по теме
Ошибка подключения MCP к базе 1С: справочник кодов ответа HTTP-сервиса
Нейросеть не видит базу 1С, а индикатор подключения зелёный. Почти всегда виновата веб-публикация, и она сама говорит об этом кодом ответа. Таблица кодов от 401 до 502 с местом поломки, командами проверки и скриптом на Node, который проходит все ступени по очереди.
MCP для 1С: один сервер на десять баз без доработки конфигураций
Десять продуктивных баз 1С в трёх странах, две конфигурации, один человек на сопровождении. Разбираем схему целиком: почему доступа к базе мало без исходников, зачем отдельная база-реестр, какие пятнадцать строк ставятся в каждую базу и чем вы за всё это платите по части безопасности.
Проверка параметров HTTP-сервиса 1С: белый список, ошибка 400 и явные умолчания
Платформа не отвергает параметры, которых обработчик не ждёт, и опечатка в имени превращается в другой запрос с кодом 200. Разбираем четыре правила строгого входа для HTTP-сервиса на встроенном языке: белый список имён, 400 с понятным текстом, видимое умолчание и возраст данных в ответе. Код на BSL и проверка за минуту.
Частые вопросы
Можно запускать на боевой публикации?
Да. Файл публикации обработка только читает, базу и настройки IIS не трогает, а в скрипте для веб-сервера нет ни одного изменяющего вызова. Живые сеансы снимаются на момент нажатия, под нагрузкой их будет больше.
У нас Apache, а не IIS. Подойдёт?
Частично. Разбор файла публикации и проверки со стороны 1С от веб-сервера не зависят, хотя на Apache их не прогоняли. Скрипт для веб-сервера написан под IIS, и для Apache половина его пунктов неприменима.
Какие права нужны?
Проверки со стороны 1С идут без доступа к веб-серверу. Скрипт для IIS запускают в PowerShell 5.1 от имени администратора: без прав модуль администрирования IIS отдаёт пустые значения вместо ошибки. Поэтому скрипт первой строкой пишет, были ли права, а ответ без прав обработка не принимает.
На какой платформе и конфигурации работает?
Заявлена платформа 8.3.10 и выше, управляемые формы, конфигурация любая. Прогоны шли на 8.3.27.1606 с IIS 10.0. Обработка рассчитана на уже работающую публикацию и первичную настройку не заменяет.
Что собирает скрипт на веб-сервере?
Пул приложений публикации с его Idle Time-out и разрядностью, время старта рабочего процесса, обработчик и модуль, ISAPI-ограничения, права на каталог публикации и web.config, ошибки 5xx и 401 из логов по подкодам и версии платформы в каталоге. Результат он кладёт в файл рядом с собой и копирует в буфер обмена.
Веб-сервер стоит на отдельной машине. Это помеха?
Обработка смотрит с машины, где работает сервер 1С, поэтому путь к файлу публикации тогда указывают сетевым. Такой путь поддержан, но прогона на раздельных машинах не было. Скрипт в любом случае запускают на самом веб-сервере.
Бесплатный экспресс-аудит вашей 1С
За 1-2 дня посмотрим вашу базу, найдём, где теряется производительность, и скажем, что с этим делать. Без обязательств.
Обсудим задачу
Быстрее всего в WhatsApp: напишите пару строк о задаче, ответим в течение рабочего дня.