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

14.10.22

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

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

Данный запрос я проверял на Управление холдингом, редакция 3.1 (3.1.15.4)

Сам запрос есть и в последних выпусках 1С:Управление холдингом, редакция 3.1.17.4 и в новой Управление холдингом, редакция 3.2.1.111.

Находится он в конфигурации здесь ОбщийМодуль.ВстраиваниеОФД.ОпределитьСрокЗакрытияЗадолженности()

Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
|	ЕСТЬNULL(РасчетыСКонтрагентамиПоДокументамОстатки.СуммаОстаток,0) + ВЫБОР
|		КОГДА ОтражениеФактическихДанныхБюджетирования.НаправлениеВзаиморасчетов = ЗНАЧЕНИЕ(Перечисление.НаправлениеДвиженияВзаиморасчетов.УвеличениеЗадолженности)
|			ТОГДА ОтражениеФактическихДанныхБюджетирования.СуммаДокумента
|		ИНАЧЕ -ОтражениеФактическихДанныхБюджетирования.СуммаДокумента
|	КОНЕЦ КАК СуммаЗадолженности
|ИЗ
|	Документ.ОтражениеФактическихДанныхБюджетирования КАК ОтражениеФактическихДанныхБюджетирования
|		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка) КАК РасчетыСКонтрагентамиПоДокументамОстатки
|		ПО РасчетыСКонтрагентамиПоДокументамОстатки.Организация = ОтражениеФактическихДанныхБюджетирования.Организация
|			И РасчетыСКонтрагентамиПоДокументамОстатки.ДоговорКонтрагента = ОтражениеФактическихДанныхБюджетирования.ДоговорКонтрагента
|			И РасчетыСКонтрагентамиПоДокументамОстатки.ОбъектРасчетов = ОтражениеФактическихДанныхБюджетирования.ОбъектРасчетов
|ГДЕ ОтражениеФактическихДанныхБюджетирования.Ссылка = &Ссылка
|";

Запрос.УстановитьПараметр("Ссылка", ДокОбъект.Ссылка);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
	СуммаЗадолженности = Выборка.СуммаЗадолженности;
	Если СуммаЗадолженности = 0 Тогда
		Возврат;
	КонецЕсли;
Иначе
	Возврат;
КонецЕсли;

Проблема в том, что для каждого документа в 1С:УХ создается связанный Документ.ОтражениеФактическихДанныхБюджетирования.

 

 

Программа при его формировании каждый раз выполняет указанный запрос, собирая ВСЕ ОСТАТКИ по РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка)а затем выдергивает из общей таблицы записи с учетом фильтра по Организации, ДоговоруКонтрагента и ОбъектуРасчетов текущего документа (не комильфо прям скажем).

 

 

В результате более 40% времени проведения документа уходит на выполнение запроса к остаткам. Ниже привожу замер производительности типового кода 1С:УХ проведения 24 документов реализации, где верхняя строчка ссылается на указанный запрос, показывая большие затраты времени на его выполнение: 

 

 

ПРИМЕЧАНИЕ: Я это делал с базой 1С:УХ крутящейся на СУБД PostgresSQL поэтому выполнение запросов может отличаться от MS SQL (там запрос выполниться оптимальнее, возможно совсем без задержки).

Вариант оптимизации простой - не собирать каждый раз все остатки.

Требуется исправить

РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка)

добавив отбор по Организации, ДоговоруКонтрагента и ОбъектуРасчета, вот так

РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка И Организация = &Организация И ДоговорКонтрагента = &ДоговорКонтрагента И ОбъектРасчетов = &ОбъектРасчетов)

К тому же для этого все есть:

  • Есть и поля в самом регистре

 

 

  • Есть в контексте процедуры переменная ДокОбъект, где просто через точку получим их: ДокОбъект.Организация, ДокОбъект.ДоговорКонтрагента, ДокОбъект.ОбъектРасчетов

В итоге выходим на такой запрос, который выполняется в 100 раз быстрее исходного

Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
|	ЕСТЬNULL(РасчетыСКонтрагентамиПоДокументамОстатки.СуммаОстаток,0) + ВЫБОР
|		КОГДА ОтражениеФактическихДанныхБюджетирования.НаправлениеВзаиморасчетов = ЗНАЧЕНИЕ(Перечисление.НаправлениеДвиженияВзаиморасчетов.УвеличениеЗадолженности)
|			ТОГДА ОтражениеФактическихДанныхБюджетирования.СуммаДокумента
|		ИНАЧЕ -ОтражениеФактическихДанныхБюджетирования.СуммаДокумента
|	КОНЕЦ КАК СуммаЗадолженности
|ИЗ
|	Документ.ОтражениеФактическихДанныхБюджетирования КАК ОтражениеФактическихДанныхБюджетирования
//+ Малышев Д.А. 2022-08-09, Заявка № 000000571
//было_н 
//|		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка) КАК РасчетыСКонтрагентамиПоДокументамОстатки
//было_к    
|		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РасчетыСКонтрагентамиПоДокументам.Остатки(, ДокументРасчетов <> &Ссылка И Организация = &Организация И ДоговорКонтрагента = &ДоговорКонтрагента И ОбъектРасчетов = &ОбъектРасчетов) КАК РасчетыСКонтрагентамиПоДокументамОстатки
//- Малышев Д.А. 2022-08-09, Заявка № 000000571
|		ПО РасчетыСКонтрагентамиПоДокументамОстатки.Организация = ОтражениеФактическихДанныхБюджетирования.Организация
|			И РасчетыСКонтрагентамиПоДокументамОстатки.ДоговорКонтрагента = ОтражениеФактическихДанныхБюджетирования.ДоговорКонтрагента
|			И РасчетыСКонтрагентамиПоДокументамОстатки.ОбъектРасчетов = ОтражениеФактическихДанныхБюджетирования.ОбъектРасчетов
|ГДЕ ОтражениеФактическихДанныхБюджетирования.Ссылка = &Ссылка
|";

Запрос.УстановитьПараметр("Ссылка", ДокОбъект.Ссылка);  
//+ Малышев Д.А. 2022-08-09, Заявка № 000000571 
Запрос.УстановитьПараметр("Организация", ДокОбъект.Организация);
Запрос.УстановитьПараметр("ДоговорКонтрагента", ДокОбъект.ДоговорКонтрагента);
Запрос.УстановитьПараметр("ОбъектРасчетов", ДокОбъект.ОбъектРасчетов);
//- Малышев Д.А. 2022-08-09, Заявка № 000000571
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
	СуммаЗадолженности = Выборка.СуммаЗадолженности;
	Если СуммаЗадолженности = 0 Тогда
		Возврат;
	КонецЕсли;
Иначе
	Возврат;
КонецЕсли;

Чего добились для себя

Мы исправляли логику проводок по Бух учету у реализаций и возвратов в 1С:УХ и потребовалось перепровести примерно 300 000 документов за первую половину 2022 года. Запустили проведение, получили что 100 000 документов провелось за 4 суток (все 300 000 просто не долждались, решили посмотреть в чем тормоза). В итоге внесли это исправление и после него 100 000 документов проводятся за 1.5 суток, вместо 4.

Выкладываю исправление, т.к. 1С:УХ стоит у многих, поэтому может пригодиться данное испавление.

Всем добра.

 
 Другие публикации автора

 

управление холдингом ускорение проведения

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта 1С v8.3 Управляемые формы Запросы Система компоновки данных Платные (руб)

Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

15500 руб.

02.09.2020    196083    1085    409    

1006

Запросы Программист 1С v8.3 Запросы 1C:Бухгалтерия Бесплатно (free)

Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть.

11.10.2024    9525    XilDen    38    

101

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

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

5 стартмани

15.02.2024    15870    308    ZAOSTG    100    

122

HighLoad оптимизация Системный администратор Программист Бесплатно (free)

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

20.11.2023    17664    ivanov660    7    

83

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

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

15.11.2023    9387    a.doroshkevich    23    

76

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

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

11.10.2023    21768    skovpin_sa    15    

106

Запросы HighLoad оптимизация Программист Запросы Бесплатно (free)

Многие знают, что для ускорения работы запроса нужно «изучить план». При этом сам план обычно обескураживает: куча разноцветных иконок и стрелочек; ничего не понятно, но очень интересно! Аналитик производительности Александр Денисов на конференции Infostart Event 2021 Moscow Premiere рассказал, как выполняется план запроса и что нужно сделать, чтобы с его помощью находить проблемы производительности.

20.06.2023    38370    Филин    37    

124
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. quazare 3941 10.08.22 17:02 Сейчас в теме
Это ты уточнил и увеличил количество измерений при связи таблиц? Да, это хороший типовой ход.

Похоже где-то подобные запросы делаются на скорую руку с первого раза

Слушай, неужели если еще заявки типа «убыстрить что-то»??? ))))))
2. sapervodichka 6974 10.08.22 17:11 Сейчас в теме
(1) добавлял только отбор в запрос. Измерения регистра и связи таблиц там все типовое. Заявки убыстрить как таковой не было, была заявка провести 300000 документов, чтобы скорректировать проводки. Но в разумные сроки, это не получалось. Решил посмотреть почему и вот на тебе, даже не поверил сначала что так в типовой УХ криво сделано и никто не исправляет (даже в крайних релизах УХ это чудо есть)
ybatiaev; RustIG; +2 Ответить
30. triviumfan 102 12.08.22 14:53 Сейчас в теме
(2)
даже не поверил

Не ну такой опытный, а до сих пор удивляешься! :) Да в любой конфе таких запросов можно сотню найти. И не важно, что УХ стоит такие денжища, процесс разработки все тот же)
31. sapervodichka 6974 12.08.22 16:59 Сейчас в теме
(30) с PostgresSQL будем чаще улыбаться, я так понял по комментам, что именно на нём болячки вылезать начинают
Дмитрий74Чел; +1 Ответить
52. Дмитрий74Чел 249 01.09.22 18:21 Сейчас в теме
(2) увы, авторы УХ это не авторы ЕРП. В ЕРП худо-бедно контроль за кодом выстроен. Такие ляпы почти не встречаются. А вот в УХ я такой "красоты" насмотрелся вдоволь.
3. quazare 3941 10.08.22 17:57 Сейчас в теме
Слушай, я не знаю ни одного документа в бухучете, который бы чето там рассчитывал для проводки. Все цифры на форме. Ну закрытие месяца не считается

Речь идет о бух учете???? Точно? Провдки по плану счетов?
6. sapervodichka 6974 10.08.22 18:14 Сейчас в теме
(3) проводок непосредственно не касается, правка ускоряет всю транзакцию проведения документа
4. quazare 3941 10.08.22 18:03 Сейчас в теме
Есть еще один лайфхак - когда ты делаешь перепроведение. Я так понимаю, изачально идет удаление проводок документа, а потом запись.

Я как-то заморочился и удалил их скулем за раз. А потом проводил - записывал проводки.
5. quazare 3941 10.08.22 18:07 Сейчас в теме
(4) но, это кропотливая работа...
7. sapervodichka 6974 10.08.22 18:16 Сейчас в теме
(5) пытливый ум, решение найдёт *)
8. RustIG 1884 10.08.22 19:27 Сейчас в теме
9. Glukamaster 6 10.08.22 20:12 Сейчас в теме
Соединять с виртуальной таблицей (по факту с вложенным запросом) не есть хорошо ибо более чем уверен, что там тупо нестет луп идет. Было бы правильно собрать данные во временные таблицы, проиндексировать по соединяемым полям, а потом эти временные таблицы соединять.
Alsegan; ybatiaev; spec8s; +3 Ответить
10. sapervodichka 6974 10.08.22 21:00 Сейчас в теме
(9) время выполнения после текущего исправления стало 0,01 секунды, поэтому дальше копать не стал
d4rkmesa; ybatiaev; +2 Ответить
29. Glukamaster 6 12.08.22 09:43 Сейчас в теме
(10) Вообще думаю повезло, ибо вероятнее оптимизатор сделал план запроса , в котором сначала отработал по индексу "Организация, ДоговорКонтрагента, ОбъектРасчетов", а потом выполнил условие ДокументРасчетов <> &Ссылка. А может такого не сделать и тупо перебирать записи. Но даже так будет быстрее работать, нежели в исходном варианте.
65. s22 23 01.07.23 18:45 Сейчас в теме
(9)
1 выборка в постгре во временные только однополосная
2 индексы не будут работать потому что 1с делает mergejoin=off
11. shard 282 10.08.22 21:49 Сейчас в теме
Статье плюс однозначно. Здесь хотя бы запрос короткий. В КА 2.5 запросы для формирования проводок попробуйте выцепить, был неприятно удивлен их размерами.
12. sapervodichka 6974 10.08.22 22:10 Сейчас в теме
(11) ну да, согласен, тут у меня скорее не исследовательская статья, а так сказать наткнулся на прикол
13. CheBurator 3230 10.08.22 22:55 Сейчас в теме
вопрос в том почему так криво написан запрос изначально?
м.б. исправленный вариант запроса будет неправильным при каких-нибудь других настройках ведения взаиморасчетов? а неисправленный исходный запрос - хоть и медленный но всегда правильный?
14. sapervodichka 6974 10.08.22 23:06 Сейчас в теме
(13) пока бездоказательно глаголешь, приводи контрпример и будем разговаривать )))
15. CheBurator 3230 10.08.22 23:20 Сейчас в теме
(14) я не настаиваю на истинности, я спрашиваю.
16. sapervodichka 6974 10.08.22 23:25 Сейчас в теме
(15) вот смотри, сам запрос маленький и выполняется тут же сразу (никуда дальше не передается). Исправление виртуальных параметров очевидное не требует экспертных знаний (т.к. в запросе уже есть эти отборы в соединении таблиц и значение полей берутся из ссылки на 1 документ).

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

Думаю они заметят его и починят.... так всегда было.
starik-2005; +1 Ответить
21. ivanov660 4746 11.08.22 07:25 Сейчас в теме
(16) Думаю, что проверяли на небольшой демонстрационной базе и на MS SQL. А MS SQL работает хорошо и скорее всего "пробрасывает" условия соединения внутрь виртуальной таблицы. Когда я анализировал подобные запросы, то было видно именно такое отличие между этими СУБД.
С другой стороны, если бы вендор писал оптимально и без ошибок, то не было бы необходимости в наших услугах.
d4rkmesa; starik-2005; sapervodichka; +3 Ответить
24. 3dice 28 11.08.22 07:45 Сейчас в теме
(16)Поверь, знание о параметрах виртуальных таблиц приравнивается к экспертным знаниям :)
44. starik-2005 3180 19.08.22 10:42 Сейчас в теме
(24)
о параметрах виртуальных таблиц
А я думал, что вообще отличать временные таблицы от виртуальных ныне только эксперты умеют )))
26. 3dice 28 11.08.22 07:51 Сейчас в теме
(15)Спрашивают с лохов. А в форумах интересуются. Тебе интересно, почему исправленный запрос работает быстрее?
23. 3dice 28 11.08.22 07:40 Сейчас в теме
(13)Глупости. В самом запросе в условии соединения ПО уже все написано. Но ПО это почти как ГДЕ.
17. CheBurator 3230 11.08.22 00:32 Сейчас в теме
(16) то есть можно сказать что тот кто писал исходный запрос - по квалификации ощутимо ниже среднего?
18. sapervodichka 6974 11.08.22 00:39 Сейчас в теме
(17) Конечно же так сказать нельзя, что ниже среднего. В 1С ниже среднего не берут. Это просто конкретный запрос из десятков тысяч оптимальных запросов в УХ, именно его разрабы 1С просто упустили из вида, им его поправить на раз.
Это я скорее о себе могу сказать, что-то средненькое. А ты только не скажи, что это ты этот запрос написал ))) а то я умру от смеха
19. CheBurator 3230 11.08.22 00:53 Сейчас в теме
(18) я на снеговика не прогаю, спи спокойно ;-)
.
Тут как раз вопрос о том, что значит "упустили из вида"...? Не подумали что будет большой объём данных и галабали на скорую руку? Не понимают как писать более-менее оптимально? Что-то иное?
.
Из исправления запроса я бы оценил что кардинально запрос не изменен, запрос не на пять экранов где реально можно налажать ненароком. То есть оптимизация запроса для среднего специалиста - очевидна. И при этом запрос исходный очень не оптимальный, т. Е. Не использованы основные принципы написания запроса...
sapervodichka; +1 Ответить
20. sapervodichka 6974 11.08.22 01:03 Сейчас в теме
25. 3dice 28 11.08.22 07:49 Сейчас в теме
(19)Судя по твоим рассуждениям, ты бы не стал править запрос, побоявшись что можешь еще где-то налажать :)
22. 3dice 28 11.08.22 07:36 Сейчас в теме
Красавчик. Отличная работа. Да, за неиспользование параметров виртуальных таблиц - точно расстрел.
27. muskul 11.08.22 08:34 Сейчас в теме
в 1с сегодня такого вагон и маленькая телешка. к сожалению
28. nicxxx 255 11.08.22 22:54 Сейчас в теме
(9) не надо всегда тупо следовать рекомендациям ЗАО 1С.
(21) в точку! я тоже исследовал - https://infostart.ru/1c/articles/880836/
Фича MSSQL - predicate pushdown. Соединение с виртуальной таблицей подхватывает параметр &Ссылка.
В Postgres такой фичи не было, не знаю как сейчас, поэтому ВТ собирает реально все данные, а там могут быть миллионы строк...
d4rkmesa; +1 Ответить
32. Tavalik 3433 12.08.22 17:12 Сейчас в теме
Такие разборы хорошо бы разработчикам конфигураций направлять. Универсальная почта для обращений v8@1c.ru. У команды "Управление холдингом" есть и своя почта - cpm@1c.ru. Все обращения рассматриваются в обязательном порядке.
sapervodichka; +1 Ответить
33. sapervodichka 6974 15.08.22 11:19 Сейчас в теме
(32)
cpm@1c.ru
Виталий, спасибо, скинул им
Прикрепленные файлы:
34. Alsegan 15.08.22 16:49 Сейчас в теме
(33)Надеюсь они прочтут комментарии и сделают через временную таблицу с Индексированием полей. (при доработке то понятно почему вы не исправляли - 1)работает , 2)больше кода контролировать при обновлении)
35. sapervodichka 6974 15.08.22 16:57 Сейчас в теме
(34) я то как раз исправил, правда не совсем понимаю почему некоторых просто параметры виртуальной таблицы не устраивают, и хотят прикрутить временную таблицу состоящую из 1 строки и её проиндексировать =)))
45. starik-2005 3180 19.08.22 10:49 Сейчас в теме
(35)
и хотят прикрутить временную таблицу состоящую из 1 строки и её проиндексировать
До сих пор некоторые 1С-нгеги всерьез полагают, что индексация бесплатна. Не так давно тут на просторах несколько добрых людей топили за то, что поиск нужно осуществлять ТОЛЬКО в индексированной таблице, потом умные существа с другой планеты провели тест, в котором поиск по индексированной таблице занимал 1 мс, а поиск на неиндексированной - 75 мс при количестве элементов около 1 кк (млн). И вроде бы вывод очевиден, да? Но оказалось, что индексация такой таблицы стоит 4,5 секунд, т.е. можно в ней 4500/75=60 раз найти без индекса что-то за то же время, за которое будет этот индекс построен. При том индекс занимает дополнительную память. Но никого это не интересует почему-то.
36. Dali 16 16.08.22 10:53 Сейчас в теме
(32) Я вас умоляю.... Поддержка 1с... У них принцип задолбать тебя вопросами и по возможности ничего не делать. Недавно в типовой обнаружил ошибку, отправил в 1с и началось:
А на последнем релизе ошибка есть?
А пришлите скриншоты и последовательность действий.
А пришлите свою базу.
Хотя и последовательность и отчет, формируемый 1С, приложил при обращении.
Спасибо ребята, никогда больше.
37. Tavalik 3433 16.08.22 15:27 Сейчас в теме
(36)
Ну это зря вы так, конечно...
sapervodichka; +1 Ответить
38. AHDP 8 18.08.22 11:21 Сейчас в теме
(0) Я правильно понимаю, что в конфигурации заложена иерархия Организация <- Договор <- Объект расчётов <- Документ?
Зачем в этом запросе вообще условия на организацию и договор?
39. sapervodichka 6974 18.08.22 13:00 Сейчас в теме
(38) индекс строится согласно порядку следования измерений в регистре, пропуская отбор по вышестоящим индексным полям замедляешь поиск
dandykry; +1 Ответить
40. AHDP 8 18.08.22 14:35 Сейчас в теме
(39) Измерения Объект расчётов и Документ должны быть проиндексированы.
41. sapervodichka 6974 18.08.22 19:35 Сейчас в теме
(40) В конфигурации УХ у данных измерений свойство Индексировать стоит "Не индексировать" поэтому индивидуальных индексов по этим полям нет.
42. AHDP 8 19.08.22 09:19 Сейчас в теме
(41)
Для MS не актуально, а слонику должно помочь. https://postgrespro.ru/docs/enterprise/14/sql-cluster
P.S. Меня интересовало условие в соединении.
53. sapervodichka 6974 01.09.22 19:51 Сейчас в теме
(42) поясни, пожалуйста, как ты понял, что ссылка на справку поможет, т.е. опиши как бы ты это применил пошагово?
43. scarabey2006 32 19.08.22 10:05 Сейчас в теме
Сделал как рекомендуется в публикации. Прибавки в скорости к сожалению не прибавило 13500 документов проводится чуть больше суток ( А уже был обрадовался, что вот оно решение оптимизации проведения.
46. starik-2005 3180 19.08.22 10:52 Сейчас в теме
(43)
Сделал как рекомендуется в публикации. Прибавки в скорости к сожалению не прибавило
А где замер производительности?
47. scarabey2006 32 19.08.22 11:58 Сейчас в теме
(46) У нас MS SQL
Прикрепленные файлы:
48. starik-2005 3180 19.08.22 12:00 Сейчас в теме
(47) Ну надо полный замер и искать там, что занимает много времени. Может в MS SQL что-то другое занимает все это время.
49. scarabey2006 32 19.08.22 12:17 Сейчас в теме
(48) Я понимаю что может в другом дело, но этот запрос отрабатывает одинаково и типовой и измененный
50. starik-2005 3180 19.08.22 12:48 Сейчас в теме
(49) Ну так выше даже писали, по какой причине - скул от мелкомягких эту ситуацию обрабатывает, фильтруя результат подзапроса.
51. scarabey2006 32 19.08.22 13:07 Сейчас в теме
(50) Надо искать дальше где оптимизировать можно (
sapervodichka; +1 Ответить
54. sapervodichka 6974 02.09.22 12:55 Сейчас в теме
В 1С ошибку приняли к исправлению
Прикрепленные файлы:
58. scarabey2006 32 01.12.22 10:33 Сейчас в теме
(54) в последнем релизе это уже исправлено ) даже в 17.23 видел, когда обновлялся
59. sapervodichka 6974 01.12.22 11:04 Сейчас в теме
(58) логично, я же им написал в августе, вот к осени и добавили исправление в релиз
55. Revachol 27.11.22 15:43 Сейчас в теме
А не правильнее было бы написать условие сразу так ("Организация = &Организация И ДоговорКонтрагента = &ДоговорКонтрагента И ОбъектРасчетов = &ОбъектРасчетов и ДокументРасчетов <> &Ссылка) исходя из структуры регистра?
sapervodichka; +1 Ответить
56. sapervodichka 6974 27.11.22 21:14 Сейчас в теме
(55) Я всегда считал что планировщик запроса при построении плана выполнения запроса выстраивает условия в нужном порядке (не зависимо от порядка, который разработчик написал), и далее этот план хранит в кеше, и использует как шаблон для повторного выполнение запроса. По порядку измерений писать условия, как ты написал - думаю правильнее будет, но выхлоп по скорости будет скорее всего тот же. Поэтому получается пофиг, но правильнее как ты говоришь (красивее точно).
57. Revachol 28.11.22 07:08 Сейчас в теме
(56)
планировщик запроса при построении плана выполнения запроса выстраивает условия в нужном порядке (не зависимо от порядка, который разработчик написал), и далее этот план хранит в кеше, и использует как шаблон для повторного выполнение запроса

Спасибо за ответ =) Покопаю эту тему)
60. Revachol 03.12.22 16:31 Сейчас в теме
(56)Дмитрий, да, ты был прав) Запрос №3,если нету "пробелов" в условии для использовании индекса - порядок не важен)
https://its.1c.ru/db/v8std/content/652/hdoc
61. check2 391 13.04.23 23:12 Сейчас в теме
Эх Ваши бы уста да в уши разработчикам... Мы этот блок тоже постоянно оптимизируем... Это просто клондайк... Достаточно ещё отметить, что при проведении ПТиУ проводится СФ, а в УХе в нагрузку ОФД, и при некоторых настройках может ещё и ВСКД проводиться (так называемая актуализация Авто) ... Эта ж жесть. Щас они хоть хешировать стали сам документ ОФД, и в случае если ключевые реквизиты его не изменяются, то он не перезаполняется и не перепроводится, а с ним и ВСКД... Но отсечение по хэшу всё равно долго работает. При восстановлении последовательности всё равно сильно сказывается. В итоге мы просто сравнивали XDTO ПТиУ до записи с XDTO записываемого с проведением документа и если они совпадали то вообще отсекали даже их алгоритмы, а вот если изменения были тогда уже их алгоритмы...
sapervodichka; +1 Ответить
62. sapervodichka 6974 13.04.23 23:21 Сейчас в теме
(61) а мы сделали проведение в несколько потоков разбив по связанным документам (200 - 400 тысяч документов в месяц, чтобы за пару дней проводились, а по умолчанию за 10 дней проводились)
63. check2 391 13.04.23 23:51 Сейчас в теме
(62) В одном из проектов было жёсткое требование к сохранению быстродействия проведения документов, и так же одной из частей было обновление УХи с 1.2 до 1.3 и как раз налетели на грабли с ОФД, которые в онлайне в 1.2 не проводились... Заказчик встал в позу. Пришлось сделать допроведение фоновым заданием. если документ проводился интерактивно и отключить совсем допроведение при восстановлении последовательности. Т.е. пользователь проводил только ПТУ, всё остальное проводилось фоном тут же. Всё что провелось с ошибками падало в регистр специальный и допроводилось вручную с предварительным разбором проблем. Тем самым мы сохранили полностью время проведения первички с 1.2 и не отрезали новый функционал.
fatman78; sapervodichka; +2 Ответить
64. sapervodichka 6974 13.04.23 23:56 Сейчас в теме
(63) Евгений, спасибо за комменты с идеями, мне и народу пригодится!
66. shura_k 11.08.23 16:25 Сейчас в теме
67. user2053365 15.02.24 16:37 Сейчас в теме
А провести документы только по интересующим регистрам не вариант? сам запрос до по логике 1совцев нормальный т.к. в соединении указаны поля соединения и по идее план запроса должен был построить выборку по этим полям, т.е. ограничение наложено в соединении. видимо платформа план запроса построила не верный.
68. sapervodichka 6974 15.02.24 18:16 Сейчас в теме
(67) Сама платформа не строит планы запроса, их строит СУБД, MS SQL и PostgreSQL строит по разному. В запросе не указан отбор поэтому быстрый индекс НЕ используется, в PostgresSQL строил неоптимальный план запроса. Вообщем 1С эту ситуацию зарегистрировали и исправили. Уже не актуально.
Оставьте свое сообщение