Почему после обращения к веб-сервису 1С сеансы остаются в памяти и как ими управлять?

При начале работы с технологией веб-сервисов в 1С разработчики часто сталкиваются с ситуацией, которая на первый взгляд кажется ошибкой или «утечкой памяти»: после завершения запроса в консоли кластера серверов продолжают отображаться активные сеансы. Давайте детально разберем, почему это происходит, чем это может быть чревато и как правильно настроить систему для оптимальной работы.

Механизм пула сеансов: зачем 1С удерживает соединения

Для начала проанализируем ситуацию с точки зрения производительности. Создание нового сеанса в 1С — это «дорогая» операция. Система должна проверить лицензию, авторизовать пользователя, инициализировать параметры сеанса и запустить код в модуле управляемого приложения. Если бы для каждого мелкого HTTP-запроса 1С создавала сеанс с нуля, время ответа увеличилось бы на несколько секунд.

Чтобы избежать этих задержек, платформа использует механизм пулинга (pooling). Когда выполнение метода веб-сервиса завершено, сеанс не закрывается немедленно, а переходит в «спящее» состояние и помещается в пул. При поступлении следующего запроса система сначала проверяет, есть ли в пуле подходящий свободный сеанс, и если есть — мгновенно отдает его в работу.

Рассмотрим основные состояния сеанса веб-сервиса:

1. Активный: в данный момент исполняется код метода веб-сервиса.
2. Спящий (в пуле): код выполнен, ответ отправлен клиенту, сеанс ждет нового вызова.
3. Завершение: время ожидания в пуле истекло, сеанс окончательно закрывается платформой.

Настройка времени жизни и переиспользования в метаданных

Выясним, как мы можем управлять этим поведением непосредственно в конфигураторе. У каждого объекта Веб-сервис есть два ключевых свойства, которые определяют его «живучесть»:

1. Использование сеансов (Reuse Sessions)
Это свойство определяет, будет ли данный веб-сервис вообще использовать механизм пула.

• Использовать — система будет стараться переиспользовать сеансы. Это рекомендуемый режим для высоконагруженных сервисов.
• Не использовать — после каждого вызова сеанс будет завершаться. Используйте это только в редких случаях, когда критически важно освобождать лицензию сразу.

2. Время жизни сеанса (Session Life Time)
Здесь задается количество секунд, в течение которых сеанс будет находиться в пуле после завершения работы. По умолчанию это значение составляет 20 секунд. Если в течение этого времени поступит новый запрос с теми же параметрами авторизации, сеанс «оживет». Если нет — он будет уничтожен «сборщиком мусора» системы 1С.

Тонкая настройка через файл публикации (default.vrd)

Часто настроек в метаданных недостаточно, особенно если нужно ограничить общее количество соединений на уровне веб-сервера (IIS или Apache). Разберем параметры в файле default.vrd, которые находятся внутри секции <pool>. Эти настройки позволяют управлять пулом более глобально.

Проанализируем пример структуры файла конфигурации:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system" 
       base="/MyWebService" 
       ib="Srvr='ServerName';Ref='BaseName';">
    <ws>
        <pool size="10" 
              waitTimeout="5" 
              keepAlive="30" 
              maxConnections="20"/>
    </ws>
</point>

Разберем значение каждого атрибута:

• size: это максимальное количество «спящих» сеансов, которые веб-сервер готов удерживать в пуле. Если лимит превышен, лишние сеансы будут закрываться сразу.
• waitTimeout: время ожидания (в секундах) в очереди, если все сеансы заняты, а новые создавать нельзя.
• keepAlive: аналогично времени жизни в метаданных, определяет, как долго удерживать сеанс.
• maxConnections: жесткий лимит на общее количество одновременных подключений к данному ресурсу.

Лицензирование: главный риск «висящих» сеансов

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

Рассмотрим ситуацию: у вас есть 50 лицензий. Если настроить время жизни сеанса веб-сервиса в 10 минут (600 секунд) и к вам часто обращаются внешние системы под разными учетными записями, вы можете быстро обнаружить, что обычные пользователи не могут войти в программу, так как все лицензии заняты «ожидающими» сеансами веб-сервисов.

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

Почему не работают глобальные переменные?

Посмотрим на проблему сохранения состояния, которую упомянул автор темы. Даже если сеанс переиспользуется, 1С гарантирует изоляцию вызовов. Это означает, что значения глобальных переменных в модуле управляемого приложения или модуле веб-сервиса могут не сохраняться или вести себя непредсказуемо между разными вызовами.

Если вам нужно передать данные между двумя последовательными вызовами веб-сервиса от одного и того же клиента, используйте следующие механизмы:

1. Параметры сеанса: они сохраняются, пока сеанс жив в пуле.
2. Временные таблицы или регистры сведений: для надежного хранения данных с привязкой к какому-либо идентификатору (например, ID сессии клиента).
3. Передача состояния через клиента: клиент получает токен или структуру данных в одном запросе и передает её обратно в следующем.

Влияние отладки на поведение сеансов

Выясним причину, по которой автор темы мог видеть «бесконечно висящие» сеансы. Если на сервере включен режим отладки, и сеанс веб-сервиса был «захвачен» отладчиком (или просто готов к захвату), платформа может удерживать его значительно дольше положенных 20 секунд. Это сделано для того, чтобы разработчик успел проанализировать состояние системы. В продуктивной среде без включенной отладки сеансы будут закрываться строго по расписанию.

Итоги и выводы

Подводя итог, можно сказать, что «висящие» в памяти сеансы — это не баг, а фича (механизм пулинга). Чтобы система работала стабильно, придерживайтесь следующих правил:

• Проверьте свойство Использование сеансов в метаданных — оно должно быть включено для производительности.
• Установите разумное Время жизни сеанса (стандартных 20 секунд обычно хватает).
• Если лицензий мало, а запросы идут от разных пользователей, уменьшайте время жизни до минимума.
• Для хранения состояния между вызовами используйте Параметры сеанса, а не глобальные переменные.
• Контролируйте файл default.vrd, чтобы ограничить максимальное количество соединений к базе через веб.