Порядок получения лицензий 1С:Предприятия клиентским приложением
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
Все виды клиентов 1С:Предприятия (кроме веб-клиента) осуществляют поиск лицензии в следующей последовательности:
▫️ Если ранее лицензия была успешно получена, то выполняется попытка получения лицензии из того же файла программной лицензии или HASP ключа что и при последнем подключении
▫️ При первом подключении или в том случае если на предыдущем этапе лицензия не была найдена выполняется поиск локальных программных лицензий
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Поиск базовой лицензии на локальном компьютере
❗️ Если лицензия не была найдена, то клиент обращается за лицензией на сервер (веб-сервер), поиск выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
☝️ При этом выдача лицензии сервером имеет свои особенности:
▫️ Лицензия выдается на каждый сеанс, т.е. один клиент может занять несколько лицензий
▫️ Сервер может подключиться только к одному локальному и одному сетевому ключу одной серии
Как видим, алгоритм достаточно сложный и поиск ключей выполняется во многих местах, поэтому для ускорения запуска клиента 1С, если вы не используете аппаратные ключи, следует использовать параметр
UseHwLicenses=0 в конфигурационном файле 1cestart.cfg, который отключит поиск лицензий на аппаратных ключах.
1👍20❤1
Порядок получения лицензий 1С:Предприятия веб-клиентом
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
Веб-клиент – особый тип клиентского приложения, предназначенный для работы через браузер. Это один из самых специфичных и ограниченных в возможностях клиентов и поэтому работу через него надо избегать.
Однако в ряде случаев особых альтернатив ему нет, например, для техники Apple или планшетов Andriod.
Получение лицензий таким клиентом имеет свои особенности и зависит от режима работы.
Для файловой базы поиск производится на компьютере, где установлен модуль расширения веб-сервера, все лицензии выдаются только в многопользовательском режиме (на сеанс):
▫️ Получение лицензии из файла программной лицензии или HASP ключа откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной файловой лицензии
▫️ Поиск локального ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
Для клиент-серверных баз локальный поиск ключа на компьютере с установленным модулем расширения веб-сервера не производится, лицензия сразу запрашивается с сервера. Поиск лицензии выполняет менеджер кластера, на который назначен сервис сеансовых данных в следующем порядке:
▫️ Программная лицензия или ключ защиты HASP откуда была получена лицензия при последнем удачном подключении
▫️ Поиск локальной программной лицензии
▫️ Поиск локального клиентского ключа HASP
▫️ Поиск сетевого ключа HASP доступного через HASP LM
▫️ Программная лицензия на сервере лицензирования откуда была получена лицензия при последнем удачном запуске
▫️ Поиск программной лицензии на сервере лицензирования
При этом, если вы используете веб-клиент для подключения к файловым и клиент-серверным базам одновременно вам будет необходимо держать два комплекта лицензий на веб-сервере и сервере 1С Предприятие в количестве достаточном для запуска нужного числа сеансов.
👍5❤4
-50% на всё лето!
Мы решили продлить летнюю распродажу до конца августа — забирайте круглогодичный IT-must-have по летним ценам:
🔥До конца августа:
Курсы для разработчиков, инженеров и DevOps со скидкой -50% по промокоду LETO2025
🔅 Gitlab CI/CDр.25 000 р.12 500
🔅 Безопасность проекта c Keycloakр.25 000 р.12 500
🔅 Безопасность в Kubernetesр.45 000 р.22 500
🔅 Data-инженерр.35 000 р.17 500
🔅 Golang-разработчикр.45 000 р.22 500
🔅 Terraform: автоматизация инфраструктурыр.30 000 р.15 000
И еще 17 курсов по выгодной цене 👉🏻 смотреть
Учитесь в удобном темпе, даже в отпуске, а после обучения получите сертификат и добавьте весомую строчку в резюме.
🏖 Выбрать курс со скидкой
Мы решили продлить летнюю распродажу до конца августа — забирайте круглогодичный IT-must-have по летним ценам:
🔥До конца августа:
Курсы для разработчиков, инженеров и DevOps со скидкой -50% по промокоду LETO2025
🔅 Gitlab CI/CD
🔅 Безопасность проекта c Keycloak
🔅 Безопасность в Kubernetes
🔅 Data-инженер
🔅 Golang-разработчик
🔅 Terraform: автоматизация инфраструктуры
И еще 17 курсов по выгодной цене 👉🏻 смотреть
Учитесь в удобном темпе, даже в отпуске, а после обучения получите сертификат и добавьте весомую строчку в резюме.
🏖 Выбрать курс со скидкой
Как легко и просто «сломать» информационную базу 1С:Предприятие, не снимая «замочка» и ничего не понять?
А что, так можно? Не только можно, но и с завидной регулярностью случается. И называется это - расширения.
Вообще, расширения – это удобный механизм доработки конфигурации или исправления ошибок без внесения изменений в саму конфигурацию, но это если в умелых руках.
А если нет? Ну так любой инструмент несет в себе такие же опасности: молотком можно забить гвоздь, а можно отбить пальцы.
Так что не так с расширениями? У расширений есть три типа назначения, про них в документации написано следующее:
Расширение с назначением Исправление предназначено для исправления ошибок в конфигурации. Поэтому оно применяется к конфигурации первым.
Затем применяется расширение с назначением Адаптация. Оно содержит доработки конфигурации при внедрении у конкретного заказчика.
И последним применяется расширение с назначением Дополнение. Оно содержит различные дополнительные сервисы, предназначенные для конфигурации (например, набор дополнительных отчетов).
Предполагается, что расширения с одинаковым назначением не должны «пересекаться» по функционалу и «мешать друг другу».
Ключевая фраза - мешать друг другу, с оговоркой – предполагается.
Что происходит на самом деле? Допустим у нас есть код какого-либо модуля и есть расширения, затрагивающие этот модуль. При запуске 1С берет исходный код модуля и применяет к нему расширение с назначением Изменение. Тем самым получает некоторый промежуточный код, который будет содержать исправления ошибок.
Потом к этому промежуточному коду применится расширение с типом адаптация и мы снова получим некий промежуточный код.
Затем уже к нему применится дополнение, и мы получим некоторый результирующий код.
Если расширений с одним назначением несколько, то они будут применяться в том порядке, в котором были добавлены в информационную базу и изменить этот порядок нельзя.
Если стараться следовать предложенным производителем стандартам, то система получается достаточно логичной. Если исправления ошибок конфликтуют с доработками или дополнениями, то у вас отключатся последние, а исправления применятся.
Если дополнение конфликтует с доработками (адаптация), то откажется работать дополнение. Но в жизни все может быть совсем по-другому. И дополнение с типом адаптация, добавленное первым, может спокойно при обновлении сломать ваши доработки.
Но чаще всего мы получаем странные глюки и ошибки буквально из неоткуда и по абсолютно непонятной причине.
А почему? А потому что раньше процесс изменения конфигурации был делом достаточно сложным и затратным: нужно было найти программиста, заплатить ему денег, снять конфигурацию с замочка, что удорожало ее поддержку и сопровождение… Поэтому чаще всего обходились сравнительно безобидными внешними отчетами и обработками.
Если же решались на доработку, то занимался этим какой-никакой, но специалист.
Зато теперь – полная свобода самовыражения. Пошли на Инфостарт, накачали расширений и давай «прокачивать» базу. И никаких программистов не надо. Даже конфигуратор открывать не придется.
И, как часто бывает, прокачивая какое-то одно направление мы с большой вероятностью столкнемся с тем, что применяемые расширения где-то пересекаются и начинают мешать друг другу. Причем этот процесс может быть абсолютно непредсказуемым.
Например, в базе А набор расширений может работать без ошибок, а в точно такой же базе Б – глючить напропалую. А почему? А потому что расширения добавлены в разном порядке. Следовательно итоговый код будет разным, с разными последствиями.
Как быть? Да никак, расширения стали нормой жизни, их будут качать и ставить. Но всегда надо иметь это ввиду и при непонятном поведении базы сразу проверять список расширений.
Ну и стараться все-таки, хотя бы по диагонали, смотреть в код расширений, прежде чем их ставить и контролировать из пересечение. Не умеете сами – позовите специалиста.
А что, так можно? Не только можно, но и с завидной регулярностью случается. И называется это - расширения.
Вообще, расширения – это удобный механизм доработки конфигурации или исправления ошибок без внесения изменений в саму конфигурацию, но это если в умелых руках.
А если нет? Ну так любой инструмент несет в себе такие же опасности: молотком можно забить гвоздь, а можно отбить пальцы.
Так что не так с расширениями? У расширений есть три типа назначения, про них в документации написано следующее:
Расширение с назначением Исправление предназначено для исправления ошибок в конфигурации. Поэтому оно применяется к конфигурации первым.
Затем применяется расширение с назначением Адаптация. Оно содержит доработки конфигурации при внедрении у конкретного заказчика.
И последним применяется расширение с назначением Дополнение. Оно содержит различные дополнительные сервисы, предназначенные для конфигурации (например, набор дополнительных отчетов).
Предполагается, что расширения с одинаковым назначением не должны «пересекаться» по функционалу и «мешать друг другу».
Ключевая фраза - мешать друг другу, с оговоркой – предполагается.
Что происходит на самом деле? Допустим у нас есть код какого-либо модуля и есть расширения, затрагивающие этот модуль. При запуске 1С берет исходный код модуля и применяет к нему расширение с назначением Изменение. Тем самым получает некоторый промежуточный код, который будет содержать исправления ошибок.
Потом к этому промежуточному коду применится расширение с типом адаптация и мы снова получим некий промежуточный код.
Затем уже к нему применится дополнение, и мы получим некоторый результирующий код.
Если расширений с одним назначением несколько, то они будут применяться в том порядке, в котором были добавлены в информационную базу и изменить этот порядок нельзя.
Если стараться следовать предложенным производителем стандартам, то система получается достаточно логичной. Если исправления ошибок конфликтуют с доработками или дополнениями, то у вас отключатся последние, а исправления применятся.
Если дополнение конфликтует с доработками (адаптация), то откажется работать дополнение. Но в жизни все может быть совсем по-другому. И дополнение с типом адаптация, добавленное первым, может спокойно при обновлении сломать ваши доработки.
Но чаще всего мы получаем странные глюки и ошибки буквально из неоткуда и по абсолютно непонятной причине.
А почему? А потому что раньше процесс изменения конфигурации был делом достаточно сложным и затратным: нужно было найти программиста, заплатить ему денег, снять конфигурацию с замочка, что удорожало ее поддержку и сопровождение… Поэтому чаще всего обходились сравнительно безобидными внешними отчетами и обработками.
Если же решались на доработку, то занимался этим какой-никакой, но специалист.
Зато теперь – полная свобода самовыражения. Пошли на Инфостарт, накачали расширений и давай «прокачивать» базу. И никаких программистов не надо. Даже конфигуратор открывать не придется.
И, как часто бывает, прокачивая какое-то одно направление мы с большой вероятностью столкнемся с тем, что применяемые расширения где-то пересекаются и начинают мешать друг другу. Причем этот процесс может быть абсолютно непредсказуемым.
Например, в базе А набор расширений может работать без ошибок, а в точно такой же базе Б – глючить напропалую. А почему? А потому что расширения добавлены в разном порядке. Следовательно итоговый код будет разным, с разными последствиями.
Как быть? Да никак, расширения стали нормой жизни, их будут качать и ставить. Но всегда надо иметь это ввиду и при непонятном поведении базы сразу проверять список расширений.
Ну и стараться все-таки, хотя бы по диагонали, смотреть в код расширений, прежде чем их ставить и контролировать из пересечение. Не умеете сами – позовите специалиста.
❤6💯3
1С:Предприятие и многопоточность. Часть 2. Файловая база
По замыслу 1С файловая база предназначена для самых-самых маленьких и имеет серьезные ограничения как по размеру, так и по количеству одновременно работающих пользователей. И очень часто негативный опыт, полученный на файловых базах, переносится на всю систему 1С:Предприятие в целом.
Но начнем мы с краткого рассмотрения типов клиентов 1С, которые можно условно разделить на толстый и тонкие (сам тонкий, веб и мобильный клиенты). Основное отличие толстого клиента в том, что толстый клиент выполняет как серверный, так и клиентский код.
С файловой базой напрямую может работать только толстый клиент. А еще толстый клиент однопоточен. Все задачи ставятся в единую очередь и исполняются в один поток, преимущественно одним ядром. И критическое значение в данном случае имеет однопоточная производительность процессора и его тактовая частота.
Но, если вы уж совсем не сэкономили на процессоре, то это не доставляет пользователю существенных неудобств. Просто потому, что масштабы выполняемых задач не те. А для одного пользователя производительности даже одного потока вполне достаточно.
Кроме основного потока толстый клиент запускает второй, дополнительный поток для работы фоновых заданий. С их помощью могут выполняться как регламентные задания, так и тяжелые, длительные операции, чтобы не блокировать работу пользователя в основном потоке.
Таким образом пользователь может запустить тяжелый отчет или обработку, а сам перейти к другим разделам программы, скажем, вводить документы. И не испытывать при этом никаких особых неудобств, так как основные тяжелые вычисления будут выполняться вторым потоком.
Но следует помнить, что дополнительный поток также один и все фоновые задания будут становиться в нем в очередь. Поэтому внимательно отнеситесь к тому, что у вас запускается в фоне, особенно к регламентным заданиям:
✅ Почему тормозит 1С. Регламентные задания
Но вся эта благодать исчезает, как только в базе появляются дополнительные пользователи. Многим знакома картина, когда производительность файловой базы резко проседает уже при подключении к ней второго пользователя.
В чем тут дело? Вспоминаем, что с данными в СУБД может работать только сервер, в нашем случае сервер – это толстый клиент. Роль СУБД выполняет файловая база, которая является полноценной базой данных собственного формата.
При запуске нескольких толстых клиентов на разных рабочих местах мы получаем несколько серверов, взаимодействующих с СУБД, это приводит не только к кратному увеличению сетевого трафика и нагрузки на дисковую подсистему хранилища файловой базы, но и появлению блокировок.
Блокировка – это специальный режим работы СУБД, когда она для избежания рассогласования информации блокирует таблицы при обращении к ним одного из клиентов и остальным приходится ждать пока таблица освободиться.
А если кто-то запустил на медленном ПК длительную операцию в транзакции, то ждать будет вся сеть.
Файловая структура только все это усугубляет. Если у нас есть пять клиентов и каждый из которых хочет получить справочник номенклатуры, то все пять серверов толстого клиента по разу скачают себе этот справочник и самостоятельно займутся его обработкой. Без всякого кеширования и повторного использования.
Поэтому в файловых базах с разделяемым по сети общим ресурсом узким местом очень быстро становится не однопоточность (точнее двухпоточность), а блокировки и избыточное количество сетевого трафика. И если со вторым еще можно бороться апгрейдом или перепланировкой сети, то блокировки надежно убивают производительность уже начиная с трех-пяти активных клиентов.
Дополнительные материалы:
🔹 1С:Предприятие и многопоточность. Часть 1. Общие вопросы
По замыслу 1С файловая база предназначена для самых-самых маленьких и имеет серьезные ограничения как по размеру, так и по количеству одновременно работающих пользователей. И очень часто негативный опыт, полученный на файловых базах, переносится на всю систему 1С:Предприятие в целом.
Но начнем мы с краткого рассмотрения типов клиентов 1С, которые можно условно разделить на толстый и тонкие (сам тонкий, веб и мобильный клиенты). Основное отличие толстого клиента в том, что толстый клиент выполняет как серверный, так и клиентский код.
С файловой базой напрямую может работать только толстый клиент. А еще толстый клиент однопоточен. Все задачи ставятся в единую очередь и исполняются в один поток, преимущественно одним ядром. И критическое значение в данном случае имеет однопоточная производительность процессора и его тактовая частота.
Но, если вы уж совсем не сэкономили на процессоре, то это не доставляет пользователю существенных неудобств. Просто потому, что масштабы выполняемых задач не те. А для одного пользователя производительности даже одного потока вполне достаточно.
Кроме основного потока толстый клиент запускает второй, дополнительный поток для работы фоновых заданий. С их помощью могут выполняться как регламентные задания, так и тяжелые, длительные операции, чтобы не блокировать работу пользователя в основном потоке.
Таким образом пользователь может запустить тяжелый отчет или обработку, а сам перейти к другим разделам программы, скажем, вводить документы. И не испытывать при этом никаких особых неудобств, так как основные тяжелые вычисления будут выполняться вторым потоком.
Но следует помнить, что дополнительный поток также один и все фоновые задания будут становиться в нем в очередь. Поэтому внимательно отнеситесь к тому, что у вас запускается в фоне, особенно к регламентным заданиям:
✅ Почему тормозит 1С. Регламентные задания
Но вся эта благодать исчезает, как только в базе появляются дополнительные пользователи. Многим знакома картина, когда производительность файловой базы резко проседает уже при подключении к ней второго пользователя.
В чем тут дело? Вспоминаем, что с данными в СУБД может работать только сервер, в нашем случае сервер – это толстый клиент. Роль СУБД выполняет файловая база, которая является полноценной базой данных собственного формата.
При запуске нескольких толстых клиентов на разных рабочих местах мы получаем несколько серверов, взаимодействующих с СУБД, это приводит не только к кратному увеличению сетевого трафика и нагрузки на дисковую подсистему хранилища файловой базы, но и появлению блокировок.
Блокировка – это специальный режим работы СУБД, когда она для избежания рассогласования информации блокирует таблицы при обращении к ним одного из клиентов и остальным приходится ждать пока таблица освободиться.
А если кто-то запустил на медленном ПК длительную операцию в транзакции, то ждать будет вся сеть.
Файловая структура только все это усугубляет. Если у нас есть пять клиентов и каждый из которых хочет получить справочник номенклатуры, то все пять серверов толстого клиента по разу скачают себе этот справочник и самостоятельно займутся его обработкой. Без всякого кеширования и повторного использования.
Поэтому в файловых базах с разделяемым по сети общим ресурсом узким местом очень быстро становится не однопоточность (точнее двухпоточность), а блокировки и избыточное количество сетевого трафика. И если со вторым еще можно бороться апгрейдом или перепланировкой сети, то блокировки надежно убивают производительность уже начиная с трех-пяти активных клиентов.
Дополнительные материалы:
🔹 1С:Предприятие и многопоточность. Часть 1. Общие вопросы
👍9❤6👀2