Администрирование · 11 мин
Время жизни сеанса HTTP-сервиса 1С: единицы измерения и настройка
Разбираем, в чём измеряется время жизни сеанса HTTP-сервиса 1С, где задаются таймауты, как работает пул соединений и почему сеансы не закрываются.
Время жизни сеанса HTTP-сервиса 1С измеряется в секундах. Это значение задаётся в свойствах HTTP-сервиса в конфигураторе (параметр «Время жизни сеанса» / SessionLifetime) и определяет, сколько платформа хранит контекст сеанса между запросами клиента, прежде чем принудительно его завершить. Значение по умолчанию — 1200 секунд, то есть 20 минут.
Важно понимать, что речь идёт не о таймауте выполнения одного запроса, а о времени существования серверного сеанса, внутри которого выполняются вызовы HTTP-сервиса. Платформа 1С при работе HTTP-сервисов использует механизм сеансов с идентификатором, который передаётся между клиентом и сервером, и именно к этому сеансу применяется настраиваемое время жизни.
На практике с настройкой сталкиваются в двух ситуациях: когда сеансы «висят» на сервере и расходуют память и лицензии, либо когда, наоборот, сеанс завершается слишком рано и клиент получает ошибки при повторных обращениях. Ниже разберём, где задаётся параметр, как он взаимодействует с пулом сеансов и настройками веб-сервера, и как проверить результат.
Что такое сеанс HTTP-сервиса и зачем ему время жизни
HTTP-сервис в 1С — это объект метаданных, который позволяет опубликовать прикладную логику базы как REST-подобный интерфейс. Когда внешний клиент (другая информационная база, мобильное приложение, сайт) обращается к опубликованному сервису, платформа создаёт на сервере сеанс — выделенный контекст выполнения с подключением к базе данных.
Создание сеанса — дорогая операция: устанавливается соединение с СУБД, инициализируется контекст, при необходимости выполняется аутентификация. Чтобы не создавать сеанс заново на каждый запрос, платформа поддерживает сеанс «живым» в течение заданного времени и переиспользует его для последующих обращений того же клиента. Время жизни сеанса — это и есть предельный срок такого переиспользования, заданный в секундах.
Если за время жизни сеанса клиент не прислал ни одного нового запроса, сеанс считается неактивным и подлежит завершению. Если запросы идут регулярно, сеанс продолжает существовать, но не дольше предельного срока. Такой механизм защищает сервер от накопления «мёртвых» сеансов, которые держат память и соединения с СУБД.
Где задаётся параметр и в каких единицах
Основное место настройки — палитра свойств HTTP-сервиса в конфигураторе. Откройте ветку «Общие» → «HTTP-сервисы», выберите нужный сервис и найдите свойство «Время жизни сеанса». Значение вводится целым числом в секундах. Значение по умолчанию — 1200, что соответствует 20 минутам.
Пересчёт единиц простой: 300 секунд — это 5 минут, 3600 — час, 86400 — сутки. Платформа не принимает минуты или часы напрямую, поэтому при переносе настроек из документации веб-серверов (где таймауты иногда задаются в минутах или в формате ЧЧ:ММ:СС) значения нужно пересчитывать в секунды вручную.
После изменения свойства в конфигураторе нужно обновить конфигурацию базы данных и переопубликовать HTTP-сервис на веб-сервере (или хотя бы перезапустить пул приложений / веб-сервер), иначе старое значение продолжит действовать. Это частая причина ситуации, когда «настройку поменяли, а ничего не изменилось».
- 1Откройте конфигуратор, ветка «Общие» → «HTTP-сервисы», выберите нужный сервис.
- 2В палитре свойств найдите «Время жизни сеанса» и укажите значение в секундах (например, 600 для 10 минут).
- 3Обновите конфигурацию базы данных (F7).
- 4Переопубликуйте сервис через диалог публикации или перезапустите веб-сервер / пул приложений.
- 5Проверьте фактическое поведение: время появления и исчезновения сеансов в консоли кластера.
Как время жизни связано с пулом сеансов
При работе через веб-сервер платформа применяет механизм пула сеансов: завершённый по таймауту сеанс не уничтожается мгновенно, а возвращается в пул и может быть отдан следующему клиенту. Параметры пула задаются в файле настроек публикации default.vrd, который лежит в каталоге публикации на веб-сервере.
В файле default.vrd для элемента point (точки подключения HTTP-сервиса) доступны атрибуты poolSize и poolTimeout. Атрибут poolSize задаёт максимальное число сеансов в пуле, а poolTimeout — время ожидания свободного сеанса в миллисекундах. Обратите внимание: здесь единицы уже другие — миллисекунды, а не секунды, и смешение этих двух параметров приводит к ошибкам на порядки.
Связка работает так: «Время жизни сеанса» в конфигураторе ограничивает, сколько живёт сам сеанс, а poolSize и poolTimeout управляют очередью ожидания, когда свободных сеансов нет. Если клиентов больше, чем сеансов в пуле, лишние запросы ждут освобождения в пределах poolTimeout, а затем получают ошибку.
Влияние веб-сервера и таймаутов соединения
Между клиентом и кластером 1С стоит веб-сервер — IIS или Apache, и у него собственные таймауты, которые могут оборвать обмен раньше, чем истечёт время жизни сеанса. В IIS это, например, Connection Timeout сайта (по умолчанию 120 секунд) и настройки простоя пула приложений (Idle Time-out, по умолчанию 20 минут). В Apache — директивы Timeout и KeepAliveTimeout.
Критичный сценарий — простой пула приложений IIS: если к сервису долго нет обращений, IIS выгружает рабочий процесс, и вместе с ним теряются все сеансы пула независимо от настроек 1С. Для стабильно работающих интеграций Idle Time-out пула приложений обычно устанавливают в 0 (без ограничения) либо согласуют с ритмом обращений клиентов.
Диагностический признак такой проблемы: первый запрос после паузы выполняется заметно дольше остальных (веб-сервер заново поднимает процесс и пересоздаёт сеансы), а в журналах 1С видны новые сеансы в моменты, когда по логике времени жизни старые ещё должны были существовать.
Как выбрать значение под свою задачу
Универсального «правильного» значения нет — выбор зависит от характера нагрузки. Для частых коротких запросов (обмен данными каждые 1–5 минут) разумен диапазон 300–1200 секунд: сеанс успевает переиспользоваться, но не висит без дела. Для редких обращений (раз в час и реже) большое время жизни бессмысленно — сеанс всё равно простаивает, а ресурсы держит.
Если HTTP-сервис вызывается из другой базы 1С через HTTPСоединение, учитывайте таймаут на стороне клиента: параметр Таймаут у объекта HTTPСоединение тоже задаётся в секундах (по умолчанию 20). Этот таймаут ограничивает ожидание ответа на конкретный запрос, а не жизнь сеанса, но при длительных операциях на сервере его нужно увеличивать, иначе клиент оборвёт ожидание раньше, чем сервер закончит обработку.
Признак слишком маленького времени жизни — постоянное создание новых сеансов при регулярных обращениях и рост накладных расходов. Признак слишком большого — накопление неактивных сеансов в консоли кластера, рост потребления памяти рабочими процессами и, в файловом варианте или при серверной лицензии на сеансы, риск исчерпания лицензий.
Как выбрать действие
Проверка результата и мониторинг сеансов
Фактическое поведение проверяется в консоли кластера серверов 1С: откройте список сеансов информационной базы и понаблюдайте за сеансами с типом «HTTP-сервис». Засеките время простоя после последнего запроса клиента — сеанс должен исчезнуть примерно через заданное время жизни с учётом внутренних циклов проверки кластера, которые добавляют небольшую погрешность.
Дополнительно полезен технологический журнал: события, связанные с созданием и завершением сеансов, позволяют увидеть реальную картину по времени и убедиться, что сеансы завершаются по таймауту, а не по ошибке. Для веб-сервера смотрите журналы IIS/Apache — там видны обрывы соединений и ответы с кодами 4xx/5xx.
Как проверить результат
Исчезает примерно через заданное время жизни после последнего запроса
Висит часами либо исчезает за секунды после запроса
Сопоставимо с обычными запросами
Заметно дольше — веб-сервер пересоздаёт процесс и сеансы
Стабильные ответы 200 на регулярные обращения
Чередование ошибок 503/таймаутов с периодичностью простоя
Типичные ошибки при настройке
Первая ошибка — изменение свойства в конфигураторе без переопубликации и перезапуска веб-сервера. Настройка применяется, но работающие процессы продолжают использовать старое значение, и администратор делает ложный вывод, что параметр «не работает».
Вторая ошибка — смешение единиц измерения: секунды в конфигураторе, миллисекунды в poolTimeout, минуты в настройках IIS. Из-за этого время жизни получается в 60 или 1000 раз больше или меньше задуманного. Третья ошибка — попытка решить проблему долгих операций увеличением времени жизни сеанса, хотя запрос обрывает таймаут клиента или веб-сервера, а не сеанс 1С.
FAQ
В каких единицах задаётся время жизни сеанса HTTP-сервиса 1С?
В секундах. Свойство «Время жизни сеанса» в конфигураторе принимает целое число секунд, значение по умолчанию — 1200 (20 минут). Для пересчёта: минуты умножайте на 60, часы — на 3600.
Чем время жизни сеанса отличается от таймаута запроса?
Время жизни сеанса ограничивает существование серверного контекста между запросами одного клиента. Таймаут запроса (например, параметр Таймаут у HTTPСоединения, по умолчанию 20 секунд) ограничивает ожидание ответа на один конкретный вызов. Это независимые настройки, и увеличение одной не компенсирует другую.
Почему сеанс завершается раньше заданного времени?
Наиболее вероятные причины: веб-сервер (IIS/Apache) обрывает неактивное соединение или выгружает пул приложений по собственному таймауту простоя, либо сеанс завершён аварийно из-за ошибки в коде обработчика. Проверьте Idle Time-out пула приложений и журналы веб-сервера.
Влияет ли время жизни сеанса на расход лицензий 1С?
Да. Каждый активный сеанс HTTP-сервиса может занимать клиентскую лицензию (в зависимости от режима лицензирования). Слишком большое время жизни при массе редких клиентов приводит к накоплению сеансов и риску исчерпания лицензий — в этом случае время жизни стоит сократить.
Нужно ли перезапускать сервер после изменения настройки?
Сервер 1С перезапускать не обязательно, но нужно обновить конфигурацию базы данных и переопубликовать HTTP-сервис либо перезапустить пул приложений веб-сервера. Без этого работающие процессы продолжат использовать прежнее значение.
Что задать для интеграции с обращениями раз в 10–15 минут?
Практичный ориентир — 900–1800 секунд, чтобы сеанс гарантированно доживал до следующего обращения и переиспользовался. Параллельно убедитесь, что пул приложений IIS не выгружается по простою раньше этого интервала, иначе выигрыша от переиспользования не будет.
Что важно запомнить
Время жизни сеанса HTTP-сервиса 1С задаётся в секундах в свойствах сервиса (по умолчанию 1200). Фактическое поведение зависит ещё от пула сеансов (poolTimeout в миллисекундах в default.vrd) и таймаутов веб-сервера. После изменения настройки сервис нужно переопубликовать, а результат проверять по списку сеансов в консоли кластера.