Не указан заголовок управления сеансами или куки с идентификатором сеанса 1с
В чем отличия между сеансом и соединением? Этот, на первый взгляд, простой вопрос на экзамене 1С:Эксперт многих ставит в тупик. Несмотря на немалый опыт программирования, сформулировать четкий и правильный ответ сможет далеко не каждый специалист.
В данной статье проведем детальный разбор этого вопроса. Для начала рассмотрим по отдельности понятия сеанс и соединение в 1С:Предприятие. Отметим, что информация актуальна для версий платформы 8.2.x и 8.3.x.
Сеанс 1С
Обратимся к руководству администратора. В нем понятие сеанса определено следующим образом:
Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя.
Можно сказать, что кластер серверов не видит пользователей, вместо них он видит сеансы и сеансовые данные. В консоли управления кластером в принципе отсутствует раздел «Пользователи», под пользователями кластер понимает сеансы.
Это подтверждает визуальное представление пункта «Сеансы» – иконка отображается в виде пользователей.
Следует уточнить, что под активным пользователем не обязательно понимается клиентское соединение, это также может быть:
Сеансовые данные
Рассмотрим понятие сеансовые данные. Сеанс содержит в себе некоторую информацию, такую как:
- наименование информационной базы
- номер сеанса
- имя аутентифицированного пользователя информационной базы
- язык интерфейса
- значения параметров сеанса
- временные хранилища
- статистику работы сеанса
- информацию форм управляемого приложения
- некоторые внутренние данные платформы
Такая информация называется сеансовыми данными. Причем для каждого активного пользователя сеансовые данные свои, и актуальны они только на время его работы. Если пользователь покидает базу (завершил сеанс) – его сеансовые данные удаляются.
Данные сеансов хранятся на кластере серверов, за это отвечает менеджер кластера, именно для этого существует сервис сеансовых данных. Чтобы ускорить работу, данные сеансов кешируются в рабочих процессах и в толстых клиентах.
При перезапуске кластера серверов данные сеансов будут сохранены. В том случае если активный пользователь не выполнил ни одного обращения к кластеру в течение 20-ти минут и сеанс не назначен соединению, то сеанс удаляется вместе с его данными.
Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут.
Соединение 1С
Теперь разберемся с понятием соединение. Вновь обратимся к руководству администратора:
Соединение является средством доступа сеансов к кластеру серверов «1С:Предприятие», содержит ограниченное множество данных соединения, не отождествляется с активным пользователем.
Другими словами, с помощью соединения сеанс получает доступ к кластеру. При этом количество соединений ограничено, и как только таковое становится не нужным сеансу, оно возвращается в пул соединений.
В случае если сеанс не обращается к кластеру, то есть пользователь бездействует, ему не будет назначено соединение. Таким образом, сеанс может существовать без соединения.
Нужно отметить, что сеансовые данные хранятся на сервере, поэтому если разрыв соединения длится менее 20 минут, то на сеансе это не отразится, ведь соединение – всего лишь средство доступа.
Также соединения используются для взаимодействия процессов кластера, то есть рабочие процессы (rphost) общаются с менеджером кластера (процесс rmngr) при помощи соединений, а не с помощью сеансов.
Отличия соединения от сеансов
Для того чтобы описать основное отличие данных понятий, приведем аналогию.
Допустим, что сеанс – это пассажир, а соединение – такси. Когда пассажиру необходимо добраться домой (сеансу нужно подключится к серверу), он вызывает такси (сеансу назначается соединение из пула соединений).
Если, добравшись домой, пассажир захочет снова поехать на работу, а такси уже уехало (после подключения случился разрыв соединения), то пассажир вызывает новое такси и едет по своим делам (сеансу назначается новое соединение).
В данной аналогии наглядно представлено, что сеанс и соединение далеко не одно и тоже, и сеанс может довольно легко перенести разрыв соединения.
PDF-версия статьи для участников группы ВКонтакте
Станьте экспертом по оптимизации 1С, изучив наш курс«Ускорение и оптимизация систем на 1С:Предприятие 8.3 (2016). Подготовка на 1С:Эксперт по технологическим вопросам»
35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.
Комментарии / обсуждение (11):
1. При удалении соединения сеанс остается, ему назначается новое соединение.
2. Как я и описал, это так же средство общения между процессами. Не понятно зачем устанавливать соединения между несколькими источниками. У вас есть только 2 процессы которые в момент времени могут между собой общаться.
3. Наверняка это знают только разработчики платформы, в документации такие тонкости не описаны.
1. Теоретически это так и должно быть. Но практика показывает, что если удалить соединение, тогда сеанс тоже удаляется, при этом нового соединения ему автоматически не назначается. Кстати говоря, я ещё раз пересмотрел раздел продвинутого курса Евгения Гилёва, в котором он более кратко описывал работу в клиент-серверном режиме работы платформы, и он тоже показал и заострил внимание на том, если удалить соединение, тогда сеанс тоже удаляется. Но вот почему так происходит, тоже не объяснил. ((
5. А ещё Вы упомянули про некий ПУЛ СОЕДИНЕНИЙ. Что когда соединение больше не нужно, оно возвращается в пул соединений. Получается, что количество соединений ограничено, и находятся все они в этом пуле, и получается, что сначала соединение может быть назначено одному сеансу, затем по ненужности вернуться в пул, а через некоторое время назначиться другому сеансу?
1. Я говорю не про теорию, у меня на практике удаление соединения не приводит к удалению сеанса. Сеансу просто назначается другое соединение.
2. Причем тут 3 объекта. rphost общается с rmngr через соединение, эти соединения мы не видим в консоли.
3-4. Нельзя объединять сеанс и соединение, как минимум потому, что у соединения нет сеансовых данных. Как реализовано соединение в платформе на физическом уровне я не знаю, я не разработчик платформы, да если честно мне это все равно. На настройку кластера и оптимизацию это знание никак не повлияет. Если разработчики сделали 2 сущности, а не одну значит на то были причины, и мы можем либо тратить свое время на догадки почему они сделали именно так, либо просто принять это как есть и разобраться в том как это сейчас работает.
5. Да, все верно.
ОГО, ЧУДЕСА, в тонком клиенте и правда нету удаления сеанса, и назначается новое соединение сеансу.
У нас то просто УПП 1.3. Я все эксперименты из вашего курса и не только как правило делал на ней. А там основной режим работы: толстый клиент, обычное приложение. В обычном приложении почему-то при малейшем обрыве сети, соединение рвётся, сеанс удаляется. Даже если не надолго из сервера вытащить сетевой провод.
Да, толстый клиент работает так. Я и забыл уже что кто-то на толстом клиенте работает :)
В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.
Переиспользование сеансов
Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».
Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.
Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:
При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.
Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.
Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством.
Средства управления
- reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
- sessionMaxAge - аналог свойства ВремяЖизниСеанса;
- poolTimeout - используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
- poolSize - используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.
Например, файл default.vrd может выглядеть так:
Автоматическое переиспользование сеансов
Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.
При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.
Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).
Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.
Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.
При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.
Эта стратегия не подходит для сценариев, в которых нужно использовать сохранённое состояние сеанса на сервере. Потому что нет никакой гарантии, что при следующем вызове клиент будет подключен к тому же самому сеансу. Как мы говорили в начале, в пуле может быть несколько сеансов с одинаковыми значениями ключевых реквизитов.
Управление сеансами
После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().
Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.
Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.
Веб-сервисы в расширениях
В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.
Запаковать сборку в zip архив, прикрепить двоичные данные к именованной настройке подсистемы.
В рамках модуля с повторным использованием
- распаковываю архив,
- получаю список распакованных файлов,
- помещаю каждый из них во временное хранилище на время работы сеанса.
- относительные пути к файлам с адресами во временном хранилище помещаю в таблицу значений с индексом
В рамках обработчика ищу строку по соответствию относительного пути, если нахожу, то отдаю код 200 с телом из двоичных данных иначе 404.
Проверка работоспособности
Apache 2.4(x64) Платформа 8.3.17(x64), конфигурация в режиме совместимости 8.3.14.
Исходный тестовый файл 18 МБ, 1800+ файлов, Холодный старт 12 сек, повторный ответ в пределах 50 мсек.
Проект на GitHub ссылка
Благодарю за внимание.
Специальные предложения
При интенсивной работе можно и с сис. администратором договорится и убрать ограничение "Отсутствие возможности разместить статические файлы в папке web сервера".
Статью писал как альтернативу "размазывания" файлов в макетах и коде. Вариант передать статику в zip на клиент, распаковать в tmp и использовать локально, но думаю при использовании web клиента будут проблемы, хотя так могут быть т.к. куки с session Id могут пересекаться и "ломать" сеанс на стороне 1С.
Просмотры 2654
Загрузки 1
Рейтинг 5
Создание 11.09.20 14:05
Обновление 11.09.20 14:05
№ Публикации 1292433
Тип файла Расширение (cfe)
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Да
См. также
BIM: взаимодействие с платформой Autodesk Forge Промо
Предлагаемый пример демонстрирует широкие возможности для взаимодействия «1С:Предприятие» с платформой Autodesk Forge и позволяет вам получить базовые представления о применения технологий информационного моделирования в строительстве. Поддерживаются все версии платформы от 8.3.12 и выше до 8.3.18.
1 стартмани
25.11.2020 38581 11 kandr 2
Расширение конфигурации для Web-доступа к 1С (1С в роли back-end)
Для реализации того, чтобы 1С формировала и отдавала страницу, которую можно было бы открыть через браузер было написано расширение, которое позволяет публиковать из 1С произвольные ресурсы, будь то API, сайт или изображения / прочие файлы.
1 стартмани
01.04.2021 8850 11 SaschaG 4
Работа с картами в 1С на примере бесплатной библиотеки Leaflet
Разработка функционала отображения и выбора пунктов доставки на карте прямо в 1С с помощью бесплатной библиотеки Leaflet. Тестирование производилось на платформе 8.3.15.1534 на тонком клиенте.
1 стартмани
31.03.2021 10494 31 Parsec1C 11
В этой статье мы покажем, как взаимодействуют клиентская и серверная части платформы и какие есть особенности в использовании директив компиляции.
Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере.
Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.
Немного базовой теории
Перед тем, как перейти к содержательной части, договоримся о некоторых ограничениях:
Далее, освежим в памяти немного теории.
Директивы, в имени которых упоминается «Клиент», устанавливают ограничение на обращение к базе данных.
Процедуры или функции, написанные под директивой «Без контекста», не имеют доступа к контексту (данным) формы. Исходя из этой информации, легко представить ограничения директив по доступу к данным в виде следующей таблицы:
Опережая вопрос «Для чего же директива с самым длинным названием, если она ограничивает и использование контекста форм, и обращения к базе данных?», напомню: любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.
Не стоит забывать и про доступность вызова одних процедур и функций из других. Для этого стоит запомнить, что можно вызывать только те процедуры и функции, которые находятся под одноимённой (с родительским методом) директивой или под директивой, находящейся ниже (чем у родительского метода) согласно списку:
Теперь про серверный вызов
Самый первый серверный вызов инициализируется в момент начала сеанса работы 1С. То есть когда пользователь выполняет вход в информационную базу:
Всё очень просто:
Обратите внимание, что доступ к базе данных есть только на серверной части, а соединение между клиентом и сервером имеет ограниченную пропускную способность. Это и неудивительно – ведь соединение между клиентской и серверной частью может быть установлено даже по нестабильному низкоскоростному каналу связи (например, посредством мобильного интернета).
Кроме этого, передача данных между клиентом и сервером возможна только посредством серверного вызова.
Видим, что на стороне клиента у нас будут доступны процедуры и функции, написанные под двумя директивами из четырёх, а на стороне сервера – под тремя из четырёх.
Сейчас мы постараемся понять особенности работы системы при использовании директив и почему необходимо уметь правильно использовать каждую из существующих директив компиляции.
И в этом нам помогут наши новые друзья, знакомьтесь!
Это процесс клиентской части приложения «1С:Предприятие 8». Он запускается на компьютере пользователя и сожительствует в оперативной памяти с другими процессами (38 вкладок браузера, поток аудио из социальной сети, telegram и другие). Может порождать серверный вызов.Это процесс серверной части приложения «1С:Предприятие 8». Он существует на сервере 1С. Знает, какие клиентские сеансы в данный момент запущены, но самостоятельно не может инициировать взаимодействие с ними. Работает с клиентской частью только через полученный от неё серверный вызов. А это серверный вызов. Как было сказано выше, он порождается процессом клиентской части и призван «прислуживать» ему. Он передает запросы со стороны клиента на сторону сервера, а также занимается транспортировкой данных с клиента на сервер и обратно.
Итак, давайте рассмотрим несколько особенностей работы программного кода в «1С:Предприятие 8», написанного под разными директивами.
Действие 1. Открытие пользователем формы с данными.
В момент нажатия Пользователем кнопки открытия формы из интерфейса, происходит передача управления на Сервер. По переданным параметрам получаются необходимые для построения данные из БД и происходит формирование контекста формы, который затем отправляется на клиентскую часть. У пользователя на экране отображается запрошенная форма.Действие 2. Получение из открытой Пользователем формы дополнительных данных из Базы данных.
После выполнения метода на сервере, весь этот «пакет» транспортируется обратно. Таким образом, форма со всеми элементами и данными дважды проходит через самое узкое место системы.
Таким образом, серверный вызов не несёт лишней нагрузки, и для передачи данных между клиентом и сервером потребуется меньше ресурсов.
Кстати, именно поэтому до версии платформы 8.3.7.1759 на сложных формах для управления видимостью элементов рекомендовалось использовать панели со страницами, а не свойство «Видимость». Только начиная с этого релиза отработка изменения видимости элементов стала выполняться на стороне клиента.Действие 3. Обработка данных табличной части формы с получением дополнительной информации из Базы данных.
Явление 1. Построчная обработка табличной части на стороне клиента с организацией серверного вызова для получения дополнительной информации из базы данных.
При таком построении программного кода происходит множественное обращение со стороны клиента на сервер – по количеству элементов цикла, запущенного на стороне клиента.Явление 2. Предварительная обработка табличной части на стороне клиента с целью подготовки требуемых к обработке на сервере данных и «упаковки» их в набор параметров. Затем передача этого набора на сервер для получения дополнительной информации из базы данных.
В данном случае количество серверных вызовов сведено к минимуму за счёт предварительной подготовки параметров.Большое количество текущих серверных вызовов может свидетельствовать о неоптимальном программном коде.
Если цель серверного вызова, созданного внутри цикла – получить какую-либо информацию из базы данных, то данная операция включает в себя запрос в цикле. А это очень негативно влияет на производительность всей системы в целом.Действие 4. Выполнение обработки данных.
Когда предполагается выполнение одной и той же обработки данных из нескольких участков программного кода, разумно этот код поместить в самостоятельную процедуру или функцию. Остаётся только решить, под какой директивой её написать.
Та-дам!
Для копирования у нас есть ксерокс. Но куда его поставить? На сторону клиента или сервера? Под какой директивой его разместить?
Как было озвучено ранее – любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.
Но что произойдёт, если потребность в копировании возникнет на стороне сервера? Например, для подготовки данных, передаваемых на сторону клиента, потребуется сделать копию? Напомню – процесс серверной части не имеет возможности самостоятельно инициировать клиентские вызовы.
Вроде бы результат достигнут – и с сервера, и с клиента доступно копирование. Но для того, чтобы получить копию данных, используемых на клиенте, приходится делать серверный вызов. А это опять ведет к лишней нагрузке на соединение и временным затратам.
Не углубляясь в детали, отметим, что метод, описанный под данной директивой управления, создаётся в двух копиях – и на стороне клиента, и на стороне сервера. Это позволяет выполнить необходимые действия там, где появилась потребность в них (клиент/сервер), без лишних серверных вызовов.
С точки зрения выполнения программы результат будет одинаков. Но объяснение «почему так не надо делать» – это уже совершенно другая тема…
Вместо заключения
В данной статье мы на наглядных примерах рассмотрели влияние различных директив компиляции на такое явление системы «1С:Предприятие 8», как серверный вызов. Как видно, основная причина для выбора правильной директивы – производительность транспортировки данных между клиентской и серверной частью.
Придерживайтесь при разработке следующих правил:
- По возможности не передавайте контекст формы на сторону сервера
- Минимизируйте количество текущих серверных вызовов
- Длительные и ресурсоёмкие задачи запускайте на выполнение на стороне сервера (при возможности – в фоновом режиме).
Учитывайте потребность в доступности тех или иных видов данных, обоснованность передачи управления и не стесняйтесь при необходимости дробить процедуры и функции. И будет Вашему серверному вызову всегда легко, а Вы от пользователей Вашей программы получите «молчаливую благодарность»!
Так ли это важно думать об оптимизации? Тут имеет смысл вспомнить одну историю.Программист Иван при доработке 1С на своём предприятии сделал ошибку в выборе директивы компиляции. Из-за неё длительность одного из серверных вызовов была больше возможной на полсекунды.
Пользователей, применяющих этот функционал, – 25 человек, и каждый из них за рабочий день в среднем совершает 110 таких операций. Всего впустую за рабочий месяц потрачено 28875 секунд (21 рабочий день * 25 человек * 110 операций * 0,5 секунды) = 8,02 часов.
Иван, каково тебе осознавать, что за месяц ты задолжал своему предприятию целый рабочий день?
Читайте также: