В новой версии повышено быстродействие системы. Для этого:

•оптимизировано открытие карточек объектов системы и выполнение действий с ними;

•ускорена загрузка вложений в карточках задач и заданий;

•ускорено получение связей при открытии карточки документа.

Также оптимизирована работа системных замещений:

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

•в новой версии неактуальные системные замещения удаляются отложенно. Например, в подразделении сотрудника сменяется руководитель. Раньше в таком случае удалялись все системные замещения, настроенные на прежнего руководителя. Теперь фоновый процесс «Компания. Удаление системных замещений» периодически проверяет наличие неактуальных замещений и удаляет их только в том случае, если сотрудник и руководитель больше не связаны друг с другом в оргструктуре. Это позволяет сохранить необходимые замещения и избежать замедления работы системы.

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

В новой версии система устанавливает лимит потребления оперативной памяти для docker-контейнеров. Он рассчитывается исходя из максимально допустимого объема, при котором проверка PROCESS_MEMORY возвращает статус unhealthy. Если занимаемая память в 1,5 раза больше указанного значения, то контейнер с сервисом автоматически перезапускается. Чтобы отрегулировать лимит потребляемой памяти, нужно изменить значение в параметре value проверки PROCESS_MEMORY. Для сервисов, с которых выполнение кода передается в изолированную область, при расчете лимита дополнительно учитывается значение параметра ISOLATED_HOST_MAX_MEMORY_SIZE.

Возможность установить лимит на потребление памяти поддерживается в операционных системах с Docker Engine версии 20.10.10 и выше.

Производительность системы зависит в том числе от скорости получения связанных документов. Чтобы этот процесс не занимал длительное время, программный код должен быть оптимальным. В Directum RX 4.9 для ускорения обработки связанных документов появились методы с типом возвращаемого значения IQueryable<T>:

•GetRelatedDocuments() – получает список документов, связанных с текущим в направлении от текущего документа к связанному;

•GetRelatedFromDocuments() – получает список документов, связанных с текущим в направлении от связанного документа к текущему;

•GetRelatedAndRelatedFromDocuments() – получает список документов, связанных с текущим в любом направлении. Для оптимизации выполнения кода метод рекомендуется использовать вместо совместного вызова GetRelatedDocuments() и GetRelatedFromDocuments().

Методы GetRelated() и GetRelatedFrom() с типом возвращаемого значения IEnumerable<T> отмечены устаревшими и оставлены для совместимости. Если они используются в программном коде, то рекомендуется адаптировать его с использованием новых методов.

Теперь в СУБД на основе PostgreSQL для формирования запросов в большинстве случаев вместо запросов типа IN используются ANY, а вместо not IN – ALL. Благодаря этому:

•запросы выполняются даже при более 65 тысяч параметров, и ошибки не возникают;

•уменьшились расходы на обработку планов запросов в PostgreSQL. Это связано с тем, что запросы с разным количеством параметров ранее имели разный план запроса, а теперь один;

•сократилось потребление памяти сервисами Directum RX, так как запросы занимают меньший объем памяти сервисов.

Раньше при развертывании системы или решения прикладная разработка могла публиковаться несколько раз. Также выполнялась инициализация и применялись настройки. Например, это происходило при установке решений, которые зависят от компонента Directum RX. После каждой публикации перезапускался веб-сервер, что занимало дополнительное время.

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

При необходимости прикладную разработку можно опубликовать принудительно. Например, если разработка уже есть, но для устранения инцидентов ее нужно перепубликовать. Для этого можно воспользоваться режимом Публикация в Directum Launcher или выполнить команду dt deploy с параметром --force.

В Directum RX списки формируются с учетом прав доступа на объекты системы. В результате отображаются только те записи, на которые у пользователя есть права. Раньше в больших списках проверка прав доступа могла занимать длительное время.

В новой версии оптимизировано получение списков с учетом прав доступа. Теперь они открываются быстрее. Для этого в базу данных добавлены системные таблицы:

•Sungero_Content_EDocReadAccess – права на чтение электронных документов;

•Sungero_WF_MainTaskReadAccess – права на чтение ведущей задачи для задач, заданий, уведомлений;

•Sungero_Core_DatabookReadAccess – права на чтение всех типов справочников;

•Sungero_Core_FolderReadAccess – права на чтение папок.

Данные в перечисленных таблицах изменяются автоматически, не рекомендуется редактировать их вручную. Кроме этого, при разработке прикладного кода не следует напрямую обращаться к базе данных. Но если у вас используются SQL-запросы к списку прав доступа Sungero_System_Accessctrlent, то для ускорения получения данных рекомендуется переписать запросы с учетом новых таблиц. В следующих версиях Directum RX таблица Sungero_System_Accessctrlent станет устаревшей.

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

2.В среде разработки:

•ускорены сборка и публикация решений

•оптимизированы редакторы типов сущностей

•оптимизировано получение выборки данных из баз на основе PostgreSQL