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

Публикация № 1728112 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 требует иного уровня качества работы с точки зрения производительности. Поэтому если у вас есть возможность, то стоит рассмотреть вариант обновления конфигурации на более новую версию. Ну или по крайней мере поискать исправления ошибок в новых версиях и попробовать перенести эти исправления (а не ошибки) к себе.

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

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. capitan 2336 19.09.22 11:24 Сейчас в теме
Вспоминается...
Еж птица гордая, не пнешь, не полетит.
ИМХО специалисты 1С начали плотнее участвовать во внедрениях + данные из мониторинга фреш
Ну и конечно переходы на постгри, который настроен на качественную разработку
Некоторая печалька, что сейчас флагманом идет УХа, а там непаханные поля косяков.
ivanov660; cleaner_it; +2 Ответить
3. ivanov660 3833 19.09.22 12:38 Сейчас в теме
(1)Согласен, смотрели УХ, там действительно печалька(
2. Torin 604 19.09.22 12:13 Сейчас в теме
" Вчера закончили внедрение УТ 11.4 .. Было сложно но мы справились. разработали доп. модули/расширения/ АРМы работать стало проще... Сегодня вышла 11.5 - заказчик в бешенстве.. Расширения/ доп модули/ АРМы встали на УТ11.5 "колом".. Работаем над новым проектом внедрения УТ11.5" (С) Не моё.
Хотели как лучше, а получилось.. ;)
4. ivanov660 3833 19.09.22 12:46 Сейчас в теме
(2) В принципе такая ситуация ожидаема. По крайней мере при смене номера подредакции, у них всегда большие архитектурные изменения. Сейчас для заказчика проводим анализ по вопросу апгрейда ERP 2.4 на 2.5 и тут довольно серьезный проект.
5. Brawler 441 19.09.22 18:45 Сейчас в теме
(4) Устал бадаться по поводу всяких тупых бесполезных доработок системы ради прихоти неких ленивых бушек и манагеров, технический долг растет, уже два обновления пережил крупных с ERP 2.4 на 2.5, все проходили очень сложно, ибо приходилось по 70+% времени тратить именно на поиск и устранение косяков возникающих после обновления. Одна база прошла относительно нормально, так как изначально все нашей командой дорабатывалось, а вот второй проект уже вся моя команда на новом месте работы колупала 2,5 месяца чтобы просто обновить. Потом еще пол года разгребали говнокод в больших объемах, а сейчас взят перерыв, достигнута некая стабильность, нужно отдохнуть, текучку делаем по приоритету.
6. ivanov660 3833 19.09.22 19:08 Сейчас в теме
(5)
1. Пока они не устаканят архитектуру, то будут такие большие переделки внутренних блоков с нуля. Не понятно где это окончательное и будет ли оно. Я так понимаю, пришлось обновлять из-за себестоимости или регламентированного учета?
2. Если не секрет, то команда из скольких человек пилила обновление?
7. Brawler 441 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 Ответить
Оставьте свое сообщение

См. также

Работа с контактной информацией

Механизмы типовых конфигураций Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Уверен, все в курсе, что контактная информация опять во всех конфигурациях хранится по-новому. Связано это с появлением так называемых муниципальных адресов, где районы заменили городские округа. Сейчас происходит массовый отказ от УПП и других устаревших решений, а также массовый переход с зарубежных систем. Возникает потребность преобразовать старые адреса в новые. И тут нас всех ждёт масса неприятных сюрпризов от разработчиков БСП. О программном интерфейсе контактной информации и пойдёт речь в данной статье.

23.05.2023    2153    biimmap    39    

38

Параллельные вычисления - это просто

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

16.05.2023    1161    avalakh    2    

27

Экспертный кейс. Миграция высоконагруженных решений 1С на Linux/PostgreSQL без потерь производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Статья по итогам нашего выступления на юбилейной X конференции PGConf.Russia, где мы рассказали о подходе, при котором миграцию высоконагруженных решений 1С на Linux/PostgreSQL можно выполнить плавно и без серьезных потрясений, при этом сохранить производительность и надежность в целевом ландшафте.

27.04.2023    3610    it-expertise    12    

26

Простой способ проверки быстродействия

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Простой (а точнее, мегапростой) способ проверки быстродействия, когда очень важно его, быстродействие, улучшить

10.04.2023    2004    vkrivov@yandex.ru    14    

32

Postgres как предчувствие. Вычисляем процент импортозамещения в режиме Highload от 1С

HighLoad оптимизация Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

1С работает с СУБД Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.

23.03.2023    1636    1CUnlimited    9    

28

Как проводятся документы в типовых конфигурациях от 1С: дополнение

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

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

13.02.2023    4727    skv_79    7    

72

Избавиться от скана таблицы в плане запроса

HighLoad оптимизация Запросы Платформа 1С v8.3 Запросы Бесплатно (free)

Для запросов, содержащих "LIKE %СтрокаПоиска%". Справедливо для MS SQL и Postgres.

20.12.2022    3059    vasilev2015    31    

25

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Для того чтобы еще до внедрения информационной системы убедиться, что целевая система справится с ожидаемой нагрузкой, требуется провести нагрузочное тестирование. О том какие инструменты и методики помогут организовать подобный проект при внедрении 1С:ERP, и о том, какие неожиданные факторы могут влиять на производительность системы я и хотел бы рассказать в данной статье.

02.11.2022    4019    Tavalik    23    

34

Делаем свой интервальный регистр в ЗУП

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

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

09.09.2022    2470    vazelin    4    

30

Основные возможности работы с файлами в типовой конфигурации на БСП

Механизмы типовых конфигураций Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

07.09.2022    9130    quazare    9    

104

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    6339    Chernazem    44    

109

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    5318    sapervodichka    64    

74

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Удаление архивных данных из базы - это непростая задача как для 1С, так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С.

28.07.2022    6013    1CUnlimited    39    

45

Добавление собственного виджета в 1С:Документооборот версии 3.0

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

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

18.07.2022    2983    ArseniyFenix    2    

45

Система контроля ведения учета [БСП]

Универсальные функции Механизмы типовых конфигураций БСП (Библиотека стандартных подсистем) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данном материале рассмотрим типовой алгоритм подсистемы контроля учета БСП в конфигурациях на примерах.

18.07.2022    5462    quazare    8    

101

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

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

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    5743    it-expertise    27    

57

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    9185    Neti    7    

96

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

26.05.2022    4205    vasilev2015    20    

34

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

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Пост будет больше интересен руководителям отделов ИТ сопровождения или проектным менеджерам, перед которыми будет стоять задача решения проблемы деградации производительности баз данных 1С. Пост для тех, кому эта тема нова, нет особого опыта, и с ходу непонятно, с чего начать.

24.05.2022    4260    avolsed    15    

33

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    2422    it-expertise    19    

23

Еще раз о дополнительных реквизитах и дополнительных сведениях

Адаптация типовых решений БСП (Библиотека стандартных подсистем) Механизмы типовых конфигураций Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Дополнительные реквизиты и сведения существуют давно. Задумка очень хорошая. Суть этих механизмов понятна всем. По этому поводу написано много. Что тут можно сказать нового? Однако бес, как всегда, в деталях. Как создавали реквизиты в объектах типовых конфигураций, так и продолжаем это делать. Почему это происходит? За всех сказать не могу. Могу рассуждать только на своем примере. Являясь убежденным практиком, одно могу сказать вполне определенно. Если что-то на практике недостаточно удобно, то останется оно главным образом в теории... Если не приложить немного усилий.

11.05.2022    9331    user1374747    19    

48

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1646    ivanov660    0    

15

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3854    ivanov660    23    

69

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

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

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

05.04.2022    5438    DBOdin_Lab    33    

29

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

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

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    5882    it-expertise    92    

68

Ни в ЗУП ногой!? А мне нравится! Часть 1. Главные сложности решения, что отталкивает

Зарплата Кадровый учет Механизмы типовых конфигураций Внедрение ИТ-системы Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 2.5 1С:Зарплата и кадры бюджетного учреждения 1С:Зарплата и кадры 7.7 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бесплатно (free)

Ни для кого не секрет, что ЗУП - одно из сложнейших решений в линейке 1С. Многие разработчики и аналитики не любят им заниматься. Тяжело представить, чтоб начинающий разработчик/аналитик стал по доброй воле работать в сфере управления персоналом и расчета заработной платы. В данной серии статей будет рассказано, какие видятся плюсы в этом решении и как справляться с его минусами. Кратко расскажу, как встать на этот путь, приведу примеры выполненных задач.

03.03.2022    9331    biimmap    57    

98

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

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

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    4290    it-expertise    50    

31

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    13561    ivanov660    18    

147

Действия при добавлении своего документа в конфигурацию ERP\КА

Механизмы типовых конфигураций Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

При добавлении новых документов в типовые конфигурации ERP\КА необходимо выполнить ряд действий, которые будут описаны в данной статье. Необходимо сразу подключить наиболее часто используемые подсистемы БСП, чтобы затем к этому не возвращаться.

02.02.2022    4418    Shining_ninja    15    

80

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    7436    stg2005    105    

40

Готовые механизмы 1С: ЗУП, представления

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

Здесь будет храниться архив запросов, которые могут помочь разработчику правильно строить отчеты и получать данные в 1С: ЗУП. Статью буду периодически дополнять.

03.11.2021    7723    Margo462    19    

91

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4924    sorter1    3    

47