Что изменилось в лучшую сторону в новых версиях конфигураций ERP/УТ/КА 2.5 с точки зрения повышения производительности?

19.09.22

База данных - HighLoad оптимизация

Обзорно рассмотрим, что поменялось в лучшую сторону в конфигурации ERP 2.5 по сравнению со старыми версиями и почему.

В процессе работы с разными версиями конфигураций УТ 11, КА 2, ERP 2 накопилось определенное количество знаний в части различий их архитектуры. Что-то исчезало, что-то добавлялось, а что-то эволюционировало и улучшалось. В предыдущей статье (Исправляем проблемы производительности в конфигурации ERP - 7 примеров) мы останавливались на проблемных моментах. Однако, теперь рассмотрим положительные изменения - некоторые важные примеры, на наш взгляд. Постараемся говорить только про хорошее.

 

1) Проблема составного типа

 

Эта особенность, которая является преимуществом 1С и одновременно ее ахиллесовой пятой. Она позволяет быстро творить и создавать сложные механизмы. Но одновременно вынуждает четко следить за результатами использования и часто создает проблемы.

Смотрите как здорово выглядит сам регистр расчетов с клиентами. Он позволяет получать информацию по остаткам взаиморасчетов. И с точки зрения архитектуры с первого взгляда проблемы не видны.

 

 

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

Пользователю не нужна ссылка на заказ клиента (который на самом деле "объект расчетов"), а ему нужны различные аналитики. Ему нужен контрагент, договор, группа финансового учета, соглашение и т.п.

При выборе этой дополнительной информации происходит обращение через две точки. И мы с Вами получаем проблему - платформа автоматически соединяет основной запрос с дополнительными таблицами. Поэтому к основным двум таблицам добавляются еще 24 таблицы из составного типа:

 
 Состав составного поля "Заказ клиента" регистра "Расчеты с клиентами"

 

В результате отчет «Расчеты с клиентами» превращается в огромного страшного монстра. Для пользователей с RLS к каждой таблице будет еще добавлены таблицы RLS ограничения, что усугубляет ситуацию еще сильнее. Время выполнения запроса к базе данных увеличивается с 1 с до 100 с и более, зависит от настроек прав доступа конкретного пользовтеля. 

Приводить план не буду, можете ради примера посмотреть тут: Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

 
 Примерный запрос отчета расчеты с клиентами

 

ВЫБРАТЬ РАЗРЕШЕННЫЕ
	РасчетыСКлиентами.АналитикаУчетаПоПартнерам,
	РегистрАналитикаУчетаПоПартнерам.Организация,
	РегистрАналитикаУчетаПоПартнерам.Партнер,
	РегистрАналитикаУчетаПоПартнерам.Контрагент,
	РегистрАналитикаУчетаПоПартнерам.Договор, 
	РегистрАналитикаУчетаПоПартнерам.НаправлениеДеятельности,
	РасчетыСКлиентами.ОбъектРасчетов КАК Заказ,
	РасчетыСКлиентами.ОбъектРасчетов.ГруппаФинансовогоУчета КАК ГруппаФинансовогоУчета
	// …
ИЗ
	РегистрНакопления.РасчетыСКлиентами.ОстаткиИОбороты(
		,
		,
		Авто
	) КАК РасчетыСКлиентами
ГДЕ
	РегистрАналитикаУчетаПоПартнерам.Партнер <> ЗНАЧЕНИЕ(Справочник.Партнеры.НашеПредприятие)

 

 

Как ее решить? Уйти от составного типа. Нет составного типа - нет проблемы (это архитектурный вариант оптимизации).

Вариант решения может быть следующим. Мы добавим новый объект, который будет сразу хранить эту дополнительную информацию для отчета в себе. Варианта два:

  • регистр сведений 
  • справочник

1) В качестве примера реализации первого варианта, можно привести регистр сведений "Реестр документов". Запрос станет значительно проще. Но в текущей ситуации у нас есть несколько условий не позволяющих его использовать:

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

2) Второй вариант – создание нового справочника «объект расчетов». На этом варианте разработчики и остановились. Хороший вариант.

 

 

Вот он новый справочник с набором всех возможных желанных полей:

 


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

Данный справочник разработчики протащили во все подобные механизмы - различные расчеты с партнерами, расчеты с клиентами, расчеты по сомнительным резервам и т.д.

Также видно, то для регистра «Расчеты с клиентами» поле «Заказ клиента» наконец-то переименовали в «Объект расчетов». Но вот в регистре «Расчеты с клиентами по документам», оставили название измерения как «Заказ клиента». Но хотя-бы заменили тип на справочник. Видно, что объемная работа проведена, но не везде выполнено должным образом и мы встречаемся с недоделками. 

 

2) Производительный механизм RLS

 

Типовой механизм RLS имеет очевидную проблему быстродействия. При большом количестве групп доступа с разными ограничениями на одну таблицу производительность сильно деградирует. Эту проблему разработчики попытались решить добавлением нового механизма, который назвали производительным. На сколько мне помнится, его ввели в последних версиях ERP 2.4. С точки зрения быстродействия данный механизм показывает определенный уровень стабильности. Однако проигрывает в некоторых случаях простым шаблонам RLS при канонических условиях – без кривых отборов и сортировок. Приведем результат небольшого расследования.

Мы провели эксперименты и специально наполнили демонстрационную базу ERP несколькими миллионами документов (чуть более 2х). Приведем пример на основе заказа клиента. В качестве ситуаций сравним поведение имитации динамического списка (в консоли запросов) с настройками по умолчанию и сортировкой по полю Организация (пользователь случайно или нет ткнул на эту колонку)

1) В первом случае выигрывает простой RLS. Разница с большим отрывом – более чем в 100 раз.

 
 Простой запрос выбора из заказа клиента

 

ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 45
	заказклиента.Ссылка КАК Ссылка,
	заказклиента.Организация КАК Организация,
	заказклиента.Склад КАК Склад,
	заказклиента.Партнер КАК Партнер
ИЗ
	Документ.ЗаказКлиента КАК заказклиента  

 

 

  • Простой RLS - 5 мс

https://explain.tensor.ru/archive/explain/6ebe99d01c8f5a750153749a00ba6386:0:2022-09-14#visio

 

 

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

  • Производительный - 700 мс

https://explain.tensor.ru/archive/explain/a1677039e3b513e07541792a06b6ab22:0:2022-09-14#visio. Схема примера приведена ниже.

 

 
В этом запросе видно отличие. Объясним, почему так происходит: 

Такое отставание происходит из-за того, что в таблице «ключи доступа к объектам» по индексу выбираются все записи с необходимым типом, а так как их много, то и процесс чтения длительный. Однако, данная операция очень хорошо параллелится, за счет этого вместо 1.5 с, мы получаем всего 0.7 с. 

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


2) Во втором случае с сортировкой по организации мы видим разницу чуть более чем в 2 раза в обратную сторону

 
 Запрос с сортировкой по полю организация

 

ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 45
	заказклиента.Ссылка КАК Ссылка,
	заказклиента.Организация КАК Организация,
	заказклиента.Склад КАК Склад,
	заказклиента.Партнер КАК Партнер
ИЗ
	Документ.ЗаказКлиента КАК заказклиента  
упорядочить по 	   
	заказклиента.Организация

 

 

  • Простой RLS - 14.3 c

https://explain.tensor.ru/archive/explain/9bf536f8068b689f20e0dc0408a23ec3:0:2022-09-14#visio

 

 

Давайте рассмотрим почему так получилось: 

Схема плана запроса по структуре ничем не отличается от варианта 1, который мы рассмотрели выше. Но в таблице заказов клиента отсутствует индекс по организации. Поэтому появляется оператор последовательного сканирования "Seq Scan", который считывает 2 млн записей. Далее для каждой считываемой строки запрашивается право доступа - можно или нет показать эту строку.  Слева набор операторов до кружка "Materialize" - это условие по RLS, которое возвращает 5 записей более 2 млн раз. 

  • Производительный - 6.2 с

https://explain.tensor.ru/archive/explain/ba24ddae1e4eac7cc8a74bd0e71a7b53:0:2022-09-14#visio

 

 

Схема запроса практически осталась как в первом варианте. Только в конце добавился оператор сортировки, который заставляет планировщик выполнять прогон по таблице основного ключа, который добавляет еще немного времени. Это происходит из-за того что в отличии от первого случая обрабатывается не 45 строк, а более чем 1.6 млн. Вот мы и увидели как влияют сортировки в таблицах.

 

3) Третий случай. Проиндексируем поле "Организация" в таблице "Заказ клиента" и выполним запрос еще раз.

  • Простой RLS. Как видно, то теперь появился оператор получения данных по индексу и время выполнения запроса снизилась ниже 1 мс. Запрос похож на тот, что был в первом случае.

https://explain.tensor.ru/archive/explain/2b17253b099782026c075bf11237553b:0:2022-09-16#visio

  • Производительный запрос - 5.9 с. Схема запроса не изменилась.

https://explain.tensor.ru/archive/explain/d1bb15773d3154bcfd5d68d126e5a6e7:0:2022-09-16#visio

С точки зрения производительного механизма в схеме плана запроса отличий нет.

 

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

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

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

 

3) Упрощение запросов

 

В качестве примера возьмем АРМ «подбор товаров в документы продажи». Он знаком практически каждому пользователю и разработчику. Таких форм больше двух - еще есть в документы закупок, на ответственное хранение и т.д. И на некотором протяжении развития конфигурации мы можем попробовать проследить как менялся этот АРМ. 

 

 

В качестве примера возьмем запрос из конфигураций 2.4 и 2.5 и рассмотрим их отличия. Структуры запросов практические одинаковые в рамках выборки полей данных. Отличаются только источники (показано на рисунке ниже).

 

 

 


С источниками стало все выглядеть лучше. Исчезла из соединения одна виртуальная таблица «Свободные Остатки» и еще одна таблица "Доступные остатки планируемых поступлений". Их заменил регистр "Распределение запасов". Здорово было бы уйти еще от вложенного запроса, тогда схема начала бы "летать".

Новый механизм "работы с запасами" облегчил и другие формы - состояние обеспечения, управление перемещением и т.д.

Вроде бы все хорошо, но новый регистр «Распределение запасов» преподнес один сюрприз. Точнее реализация его логики заполнения. При большом количестве пользователей в базе и их активной работе при пересчете этого регистра могут происходить блокировки.

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

 

Резюме

 

В новой версии ERP 2.5, как мне видится, разработчики местами поправили свои огрехи и местами вернулись на истинный путь следования рекомендациям:

  • Поправили нехватку фильтров в виртуальных таблицах;
  • Переписали часть архитектурных механизмов;
  • Довели до ума производительный механизм;
  • И другое.

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

Однако, как всегда и везде, с разработкой автоматически добавляются новые вызовы. Это как с тем сусликом:

-Ты его видишь?
-Нет.
-И я не вижу. А он есть!

См. также

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7354    149    ZAOSTG    66    

95

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5766    doom2good    48    

63

Шаблоны новых объектов 1С для 1С:Бухгалтерии предприятия

Инструментарий разработчика БСП (Библиотека стандартных подсистем) Механизмы типовых конфигураций Платформа 1С v8.3 1С:Бухгалтерия 3.0 Бесплатно (free)

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

28.12.2023    4733    mrXoxot    11    

97

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8588    ivanov660    6    

75

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    4999    a.doroshkevich    20    

72

Ключи аналитик учета в ЕРП, КА, УТ

Механизмы типовых конфигураций Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Управленческий учет Бесплатно (free)

Разбираемся, зачем в системе ЕРП созданы справочники: ключи аналитик учета, зачем созданы аналогичные по набору измерений регистры сведений. Какие проблемы они решают, какие создают новые и что с этим делать.

08.11.2023    6768    ids79    25    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    15958    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. capitan 2461 19.09.22 11:24 Сейчас в теме
Вспоминается...
Еж птица гордая, не пнешь, не полетит.
ИМХО специалисты 1С начали плотнее участвовать во внедрениях + данные из мониторинга фреш
Ну и конечно переходы на постгри, который настроен на качественную разработку
Некоторая печалька, что сейчас флагманом идет УХа, а там непаханные поля косяков.
Светлый ум; ivanov660; cleaner_it; +3 Ответить
3. ivanov660 4325 19.09.22 12:38 Сейчас в теме
(1)Согласен, смотрели УХ, там действительно печалька(
Светлый ум; +1 Ответить
2. Torin 735 19.09.22 12:13 Сейчас в теме
" Вчера закончили внедрение УТ 11.4 .. Было сложно но мы справились. разработали доп. модули/расширения/ АРМы работать стало проще... Сегодня вышла 11.5 - заказчик в бешенстве.. Расширения/ доп модули/ АРМы встали на УТ11.5 "колом".. Работаем над новым проектом внедрения УТ11.5" (С) Не моё.
Хотели как лучше, а получилось.. ;)
4. ivanov660 4325 19.09.22 12:46 Сейчас в теме
(2) В принципе такая ситуация ожидаема. По крайней мере при смене номера подредакции, у них всегда большие архитектурные изменения. Сейчас для заказчика проводим анализ по вопросу апгрейда ERP 2.4 на 2.5 и тут довольно серьезный проект.
5. Brawler 453 19.09.22 18:45 Сейчас в теме
(4) Устал бадаться по поводу всяких тупых бесполезных доработок системы ради прихоти неких ленивых бушек и манагеров, технический долг растет, уже два обновления пережил крупных с ERP 2.4 на 2.5, все проходили очень сложно, ибо приходилось по 70+% времени тратить именно на поиск и устранение косяков возникающих после обновления. Одна база прошла относительно нормально, так как изначально все нашей командой дорабатывалось, а вот второй проект уже вся моя команда на новом месте работы колупала 2,5 месяца чтобы просто обновить. Потом еще пол года разгребали говнокод в больших объемах, а сейчас взят перерыв, достигнута некая стабильность, нужно отдохнуть, текучку делаем по приоритету.
6. ivanov660 4325 19.09.22 19:08 Сейчас в теме
(5)
1. Пока они не устаканят архитектуру, то будут такие большие переделки внутренних блоков с нуля. Не понятно где это окончательное и будет ли оно. Я так понимаю, пришлось обновлять из-за себестоимости или регламентированного учета?
2. Если не секрет, то команда из скольких человек пилила обновление?
grey.grouse; +1 Ответить
7. Brawler 453 19.09.22 22:21 Сейчас в теме
1. Нет предела совершенству. Себестоимость нет, она особо и не меняется, а вот регл учет в стране да меняется постоянно и программа под него. Предыдущая база начала тесто зависеть от маркировки продукции например, там изменения постоянные. Там торговля и производство тесно переплетены. Текущая база форсировался переход из-за например "Резервы под снижение стоимости материальных ценностей" прихоть главного бухгалтера, да и в целом ЭДО тоже нужно чтобы было актуально. и и и и и примеров нужных изменений не счесть.
2. Условно 4-5
8. muskul 20.09.22 01:31 Сейчас в теме
Почему в объекты расчетов забыли добавить склад/место расчетов =(
9. Alex_CheST 2 20.09.22 08:54 Сейчас в теме
А про проводки? Механизмы стали использовать. В чем их преимущество над старым типом проведения в модуле менеджера?
unknown181538; Рамзес; shkipa91; reboot; +4 Ответить
10. genayo 24.09.22 07:20 Сейчас в теме
Интересно, какую зарплату получают архитекторы В 1С. И за что им платят премии.
d4rkmesa; +1 Ответить
Оставьте свое сообщение