Почему падают веб-сервисы 1С при высокой нагрузке и как оптимизировать их работу?

← На главную

При резком увеличении количества одновременных обращений к веб-сервисам 1С (от 100–300 параллельных запросов) система может начать аварийно завершать процессы веб-сервера или службы кластера 1С, отдавать ошибки таймаутов или зависать. Разберем по шагам, почему возникает эта проблема, как провести детальную диагностику и какие архитектурные и серверные настройки позволяют стабилизировать работу интеграций под высокой нагрузкой.

Анализ времени выполнения запросов и управление сеансами

Проанализируем природу обработки вызовов в 1С. Каждый входящий синхронный SOAP- или HTTP-запрос занимает отдельный сеанс на сервере 1С на все время своего выполнения. Если вызов длится долго, пул сеансов лавинообразно разрастается, блокируя доступную память и потоки.

Выясним контрольные нормативы производительности для веб-сервисов:

Идеальное время выполнения: от 100 до 300 миллисекунд. При такой скорости один серверный сеанс успевает поочередно обслужить запросы от нескольких внешних клиентов без образования очереди.
Допустимое время: до 500 миллисекунд. Если доля таких вызовов не превышает 5–10% от общего потока, нагрузка на кластер остается в пределах нормы.
Критическое время: более 1,5–2 секунд. Если веб-сервис выполняет операцию несколько секунд, то при 200 одновременных обращениях кластер серверов попытается одновременно открыть 200 тяжелых сеансов. Это приводит к исчерпанию ресурсов рабочего процесса rphost, взаимоблокировкам на уровне СУБД и падению веб-сервера по таймауту.

Архитектурное разделение: переход от длинных синхронных вызовов к асинхронной схеме

Если специфика бизнес-логики не позволяет сократить время выполнения алгоритма до сотен миллисекунд (например, требуется расчет сложного отчета, проведение тяжелого документа или пакетная обработка данных), необходимо отказаться от ожидания результата в одном соединении. Разберем шаблон реализации асинхронного взаимодействия через фоновые задания:

Первый запрос (инициация): веб-сервис принимает параметры от внешней системы, запускает фоновое задание с помощью метода ФоновыеЗадания.Выполнить() и мгновенно возвращает вызывающей стороне уникальный идентификатор задания (УникальныйИдентификатор). Длительность этого вызова составляет менее 50 миллисекунд.
Второй запрос (опрос статуса и получение результата): внешняя система через установленный интервал (например, 1–3 секунды) обращается к сервису проверки статуса, передавая полученный идентификатор.
Завершение обработки: как только фоновое задание переходит в состояние завершения, сервис возвращает готовый результат и освобождает ресурсы.

Посмотрим на пример организации запуска фонового задания внутри веб-сервиса:


ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(ВходныеДанныеСтруктура);

ФоновоеЗадание = ФоновыеЗадания.Выполнить(
    "ИнтеграцияСервер.ВыполнитьТяжелуюОбработку",
    ПараметрыЗадания,
    Строка(Новый УникальныйИдентификатор),
    "Обработка входящего пакета веб-сервиса"
);

ИдентификаторЗадания = Строка(ФоновоеЗадание.УникальныйИдентификатор);
Возврат ИдентификаторЗадания;

Обновление платформы 1С и разрядности веб-сервера

Устаревшие версии платформы 1С (включая ветку 8.2 и ранние релизы 8.3) имеют жесткие ограничения по механизмам пулинга сеансов и распараллеливания сетевых соединений. Использование 32-разрядного веб-сервера накладывает ограничение на адресное пространство процесса (до 2–3 ГБ), которое быстро исчерпывается при разборе объемных XML-пакетов множеством потоков.

Для обеспечения стабильности выполним следующие шаги:

Обновление платформы: переход на актуальные версии платформы 1С:Предприятие 8.3, где реализован оптимизированный механизм переиспользования сеансов веб-сервисов.
Переход на 64-битный веб-сервер: использование Apache 2.4 x64 или Microsoft IIS x64. 64-разрядные модули расширения веб-сервера (wsapache24.dll или wsisapi.dll) исключают падения процесса из-за нехватки виртуальной памяти при пиковых нагрузках.

Тонкая настройка веб-сервера Apache

По умолчанию в Apache на платформе Windows модуль mpm_winnt может быть сконфигурирован на обработку малого числа одновременных потоков, из-за чего при 200–300 одновременных запросах новые подключения сбрасываются или ставятся в очередь, вызывая падение дочернего процесса httpd.exe.

Откроем конфигурационный файл httpd.conf (или httpd-mpm.conf) и скорректируем параметры многопоточности:

Увеличим лимит потоков в секции модуля mpm_winnt_module: зададим директивы ThreadsPerChild 500 и ThreadLimit 500.
Скорректируем таймауты удержания соединений: уменьшим KeepAliveTimeout до 1–2 секунд либо отключим KeepAlive Off, чтобы завершенные соединения не удерживали выделенные потоки веб-сервера.

Настройка файла публикации default.vrd

В файле публикации веб-сервиса default.vrd настроим параметры пула соединений, чтобы контролировать создание сеансов и не перегружать кластер 1С лавиной подключений.

Разберем ключевые параметры секции service и пула соединений:

reuseSessions: установим значение autouse, что позволит платформе автоматически повторно использовать свободные сеансы между разными вызовами одного и того же сервиса.
sessionMaxAge: ограничим время жизни простаивающего сеанса в пуле, чтобы не накапливать «зависшие» подключения.
pool: ограничим максимальный размер пула соединений для предотвращения исчерпания серверных лицензий и перегрузки СУБД.

Оптимизация кластера серверов 1С и СУБД

Под высокой нагрузкой один процесс rphost может стать узким местом из-за внутренней синхронизации потоков при транзакциях и парсинге данных. Настроим параметры кластера через консоль администрирования 1С:

Масштабирование рабочих процессов: зададим параметры кластера так, чтобы нагрузка распределялась на несколько процессов rphost (настройка параметров «Количество информационных баз на рабочий процесс» или «Количество соединений на рабочий процесс»).
Контроль памяти: включим параметры «Безопасный расход памяти за один вызов» и «Максимальный объем памяти рабочих процессов», чтобы аварийный вызов с утечкой памяти автоматически перезапускал только один рабочий процесс без остановки всего кластера.
Режим управления блокировками: убедимся, что для метаданных конфигурации, участвующих в обработке веб-сервисов, установлен «Управляемый» режим блокировок, что минимизирует эскалацию блокировок таблиц на уровне Microsoft SQL Server или PostgreSQL.

Локализация сбоев через Технологический журнал

Если веб-сервисы продолжают падать, определим точное место сбоя с помощью Технологического журнала 1С. Для этого настроим сбор событий в файле logcfg.xml:

События EXCP и EXCPCNTX — фиксируют все исключительные ситуации и аварийные завершения с указанием контекста кода.
События CALL — позволяют замерить точную длительность серверных вызовов и выделить самые медленные методы.
События VRS — протоколируют входящие обращения к веб-сервисам и точкам публикации.
Журнал событий операционной системы (Application Log) — позволяет по коду ошибки APPCRASH выяснить, какой именно бинарный модуль упал: httpd.exe, библиотека адаптера wsapache.dll или рабочий процесс rphost.exe.