Что такое соединение и сеанс в терминологии системы 1С предприятие? Как они взаимодействует взаимодействуют в рамках кластера серверов 1С? Чем отличается сеанс от соединения? Рассмотрим данные вопросы.

Отличие сеанса от соединения

На самом деле это совершенно разные вещи, которые никак нельзя сравнивать.

Под понятием сеанс понимается активный пользователь системы и его поток управления. Сеанс хранит в себе информацию актуальную только для данного пользователя и на время работы его: номер сеанса, пользователь, ИБ и т.д. Пример сеанса — клиентское приложение 1С, фоновое задание и т.д.

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

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

Настройка системы 04.10.2017 08:29 9371

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

В новых версиях платформы, время по прошествии которого сеанс уходит в спящий режим и время через которое удаляется сеанс, необходимо настраивать самостоятельно. По умолчанию время ухода в спящий режим составляет 1200 секунд или 20 минут, а время удаления сеансов 86400 секунд или 1 сутки. Таким образом "спящие" сеансы доступны еще в течение суток. Поэтому, при переходе на новую платформу можно заметить увеличение количества "зависших" сеансов. А на самом деле, это не "зависшие" сеансы, а просто прошло менее суток по истечении которых они должны удалиться.

Интервалы засыпания и завершения сеансов можно настроить в конфигураторе. Для этого в главном меню нужно перейти: Администрирование->Параметры информационной базы.

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

1. progv8 04.10.2017 10:22Висело с десяток не активных сеансов. После уменьшения времени засыпания пассивного сеанса и времени завершения спящего сеанса, сеансы так и остались висеть. Помогло только принудительное удаление в кластере серверов. Скорее всего настройки вступят в силу после перезапуска сервера или для новых сеансов.

Для того чтобы добавить сообщение, необходимо Войти или Зарегистрироваться

Реализовано в версии 8.3.9.1818.

В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.

Переиспользование сеансов

Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».

Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.

В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.

Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.

Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:

  • Автоматическое переиспользование сеансов из пула;
  • Управление сеансами с помощью HTTP-заголовков.

При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.

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

Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.

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

Средства управления

Необходимость использования одной или другой стратегии вы можете определить в дереве объектов конфигурации, и, при необходимости, переопределить в файле публикации default.vrd. В дереве объектов конфигурации мы добавили два новых свойства объектам Web-сервис и HTTP-сервис:

  • ПовторноеИспользованиеСеансов может принимать значения ИспользоватьАвтоматически, Использовать, НеИспользовать. Значение ИспользоватьАвтоматически включает автоматическое переиспользование сеансов из пула, а значение Использовать включает управление сеансами с помощью HTTP-заголовков.
  • В свойстве ВремяЖизниСеанса вы можете указать, сколько секунд будет бездействовать сеанс до того, как платформа завершит его автоматически.

В файле default.vrd для элементов, описывающих SOAP-сервисы, HTTP-сервисы и сервисы OData, мы ввели несколько новых атрибутов:

  • reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
  • sessionMaxAge — аналог свойства ВремяЖизниСеанса;
  • poolTimeout — используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
  • poolSize — используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.

Например, файл default.vrd может выглядеть так:

Файл default.vrd имеет больший приоритет, чем конфигурация. При публикации конфигурации атрибуты reuseSessions и sessionMaxAge заполняются из соответствующих свойств объектов конфигурации Web-сервис и HTTP-сервис. Но при необходимости вы можете изменить эти значения прямо в файле, и тогда платформа будет использовать их, а не значения из конфигурации.

Автоматическое переиспользование сеансов

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

При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.

Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).

Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.

Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.

При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.

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

Управление сеансами

Инициатором создания и завершение сеанса является клиент сервиса. Чтобы создать постоянный сеанс клиент должен передать заголовок IBSession в http – запросе. Этот заголовок вы устанавливаете вручную. Значением этого заголовка должна быть директива start.

После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().

Если клиент затребовал создание сеанса, а сервер не может это сделать, генерируется сообщение об ошибке 406 Not Acceptable.

Если всё хорошо и сеанс создан, платформа помещает в http-ответ директиву установки куки IBSession с идентификатором созданного сеанса.

Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.

Для завершения сеанса вам нужно использовать заголовок IBSession http-запроса. Его нужно установить в директиву finish.

Получив сообщение с таким заголовком, сервер отрабатывает вызов, и закрывает сеанс.

Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.

Веб-сервисы в расширениях

Если объекты конфигурации Web-сервис или HTTP-сервис располагается в расширении конфигурации, то возможность редактировать свойства ПовторноеИспользованиеСеансов и ВремяЖизниСеанса у вас отсутствует. Поэтому, если вы хотите включить автоматическое или ручное переиспользование сеансов, вам нужно использовать для этого файл default.vrd.

В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.