Ускорим проведение в 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С:УХ стоит у многих, поэтому может пригодиться данное испавление.

Всем добра.

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

 

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

См. также

SALE! 20%

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

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

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122154    670    389    

714

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

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

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

1 стартмани

15.02.2024    7635    158    ZAOSTG    67    

96

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

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

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

20.11.2023    8868    ivanov660    6    

76

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

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

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

11.10.2023    16184    skovpin_sa    14    

98

MS SQL Server: изучаем планы запросов

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

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

20.06.2023    16005    Филин    37    

113

Все консоли запросов для 1С

Запросы Инструментарий разработчика Бесплатно (free)

Список всех популярных обработок.

17.03.2023    35539    kuzyara    84    

179

Пример многопоточной обработки (БСП)

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

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

13.02.2023    9324    6    echo77    8    

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

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

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

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

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

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

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

Думаю они заметят его и починят.... так всегда было.
starik-2005; +1 Ответить
21. ivanov660 4330 11.08.22 07:25 Сейчас в теме
(16) Думаю, что проверяли на небольшой демонстрационной базе и на MS SQL. А MS SQL работает хорошо и скорее всего "пробрасывает" условия соединения внутрь виртуальной таблицы. Когда я анализировал подобные запросы, то было видно именно такое отличие между этими СУБД.
С другой стороны, если бы вендор писал оптимально и без ошибок, то не было бы необходимости в наших услугах.
starik-2005; sapervodichka; +2 Ответить
24. 3dice 19 11.08.22 07:45 Сейчас в теме
(16)Поверь, знание о параметрах виртуальных таблиц приравнивается к экспертным знаниям :)
44. starik-2005 3033 19.08.22 10:42 Сейчас в теме
(24)
о параметрах виртуальных таблиц
А я думал, что вообще отличать временные таблицы от виртуальных ныне только эксперты умеют )))
26. 3dice 19 11.08.22 07:51 Сейчас в теме
(15)Спрашивают с лохов. А в форумах интересуются. Тебе интересно, почему исправленный запрос работает быстрее?
23. 3dice 19 11.08.22 07:40 Сейчас в теме
(13)Глупости. В самом запросе в условии соединения ПО уже все написано. Но ПО это почти как ГДЕ.
17. CheBurator 3119 11.08.22 00:32 Сейчас в теме
(16) то есть можно сказать что тот кто писал исходный запрос - по квалификации ощутимо ниже среднего?
18. sapervodichka 6697 11.08.22 00:39 Сейчас в теме
(17) Конечно же так сказать нельзя, что ниже среднего. В 1С ниже среднего не берут. Это просто конкретный запрос из десятков тысяч оптимальных запросов в УХ, именно его разрабы 1С просто упустили из вида, им его поправить на раз.
Это я скорее о себе могу сказать, что-то средненькое. А ты только не скажи, что это ты этот запрос написал ))) а то я умру от смеха
19. CheBurator 3119 11.08.22 00:53 Сейчас в теме
(18) я на снеговика не прогаю, спи спокойно ;-)
.
Тут как раз вопрос о том, что значит "упустили из вида"...? Не подумали что будет большой объём данных и галабали на скорую руку? Не понимают как писать более-менее оптимально? Что-то иное?
.
Из исправления запроса я бы оценил что кардинально запрос не изменен, запрос не на пять экранов где реально можно налажать ненароком. То есть оптимизация запроса для среднего специалиста - очевидна. И при этом запрос исходный очень не оптимальный, т. Е. Не использованы основные принципы написания запроса...
sapervodichka; +1 Ответить
20. sapervodichka 6697 11.08.22 01:03 Сейчас в теме
25. 3dice 19 11.08.22 07:49 Сейчас в теме
(19)Судя по твоим рассуждениям, ты бы не стал править запрос, побоявшись что можешь еще где-то налажать :)
22. 3dice 19 11.08.22 07:36 Сейчас в теме
Красавчик. Отличная работа. Да, за неиспользование параметров виртуальных таблиц - точно расстрел.
27. muskul 11.08.22 08:34 Сейчас в теме
в 1с сегодня такого вагон и маленькая телешка. к сожалению
28. nicxxx 254 11.08.22 22:54 Сейчас в теме
(9) не надо всегда тупо следовать рекомендациям ЗАО 1С.
(21) в точку! я тоже исследовал - https://infostart.ru/1c/articles/880836/
Фича MSSQL - predicate pushdown. Соединение с виртуальной таблицей подхватывает параметр &Ссылка.
В Postgres такой фичи не было, не знаю как сейчас, поэтому ВТ собирает реально все данные, а там могут быть миллионы строк...
32. Tavalik 3350 12.08.22 17:12 Сейчас в теме
Такие разборы хорошо бы разработчикам конфигураций направлять. Универсальная почта для обращений v8@1c.ru. У команды "Управление холдингом" есть и своя почта - cpm@1c.ru. Все обращения рассматриваются в обязательном порядке.
sapervodichka; +1 Ответить
33. sapervodichka 6697 15.08.22 11:19 Сейчас в теме
(32)
cpm@1c.ru
Виталий, спасибо, скинул им
Прикрепленные файлы:
34. Alsegan 15.08.22 16:49 Сейчас в теме
(33)Надеюсь они прочтут комментарии и сделают через временную таблицу с Индексированием полей. (при доработке то понятно почему вы не исправляли - 1)работает , 2)больше кода контролировать при обновлении)
35. sapervodichka 6697 15.08.22 16:57 Сейчас в теме
(34) я то как раз исправил, правда не совсем понимаю почему некоторых просто параметры виртуальной таблицы не устраивают, и хотят прикрутить временную таблицу состоящую из 1 строки и её проиндексировать =)))
45. starik-2005 3033 19.08.22 10:49 Сейчас в теме
(35)
и хотят прикрутить временную таблицу состоящую из 1 строки и её проиндексировать
До сих пор некоторые 1С-нгеги всерьез полагают, что индексация бесплатна. Не так давно тут на просторах несколько добрых людей топили за то, что поиск нужно осуществлять ТОЛЬКО в индексированной таблице, потом умные существа с другой планеты провели тест, в котором поиск по индексированной таблице занимал 1 мс, а поиск на неиндексированной - 75 мс при количестве элементов около 1 кк (млн). И вроде бы вывод очевиден, да? Но оказалось, что индексация такой таблицы стоит 4,5 секунд, т.е. можно в ней 4500/75=60 раз найти без индекса что-то за то же время, за которое будет этот индекс построен. При том индекс занимает дополнительную память. Но никого это не интересует почему-то.
36. Dali 15 16.08.22 10:53 Сейчас в теме
(32) Я вас умоляю.... Поддержка 1с... У них принцип задолбать тебя вопросами и по возможности ничего не делать. Недавно в типовой обнаружил ошибку, отправил в 1с и началось:
А на последнем релизе ошибка есть?
А пришлите скриншоты и последовательность действий.
А пришлите свою базу.
Хотя и последовательность и отчет, формируемый 1С, приложил при обращении.
Спасибо ребята, никогда больше.
37. Tavalik 3350 16.08.22 15:27 Сейчас в теме
(36)
Ну это зря вы так, конечно...
sapervodichka; +1 Ответить
38. AHDP 8 18.08.22 11:21 Сейчас в теме
(0) Я правильно понимаю, что в конфигурации заложена иерархия Организация <- Договор <- Объект расчётов <- Документ?
Зачем в этом запросе вообще условия на организацию и договор?
39. sapervodichka 6697 18.08.22 13:00 Сейчас в теме
(38) индекс строится согласно порядку следования измерений в регистре, пропуская отбор по вышестоящим индексным полям замедляешь поиск
dandykry; +1 Ответить
40. AHDP 8 18.08.22 14:35 Сейчас в теме
(39) Измерения Объект расчётов и Документ должны быть проиндексированы.
41. sapervodichka 6697 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 6697 01.09.22 19:51 Сейчас в теме
(42) поясни, пожалуйста, как ты понял, что ссылка на справку поможет, т.е. опиши как бы ты это применил пошагово?
43. scarabey2006 28 19.08.22 10:05 Сейчас в теме
Сделал как рекомендуется в публикации. Прибавки в скорости к сожалению не прибавило 13500 документов проводится чуть больше суток ( А уже был обрадовался, что вот оно решение оптимизации проведения.
46. starik-2005 3033 19.08.22 10:52 Сейчас в теме
(43)
Сделал как рекомендуется в публикации. Прибавки в скорости к сожалению не прибавило
А где замер производительности?
47. scarabey2006 28 19.08.22 11:58 Сейчас в теме
(46) У нас MS SQL
Прикрепленные файлы:
48. starik-2005 3033 19.08.22 12:00 Сейчас в теме
(47) Ну надо полный замер и искать там, что занимает много времени. Может в MS SQL что-то другое занимает все это время.
49. scarabey2006 28 19.08.22 12:17 Сейчас в теме
(48) Я понимаю что может в другом дело, но этот запрос отрабатывает одинаково и типовой и измененный
50. starik-2005 3033 19.08.22 12:48 Сейчас в теме
(49) Ну так выше даже писали, по какой причине - скул от мелкомягких эту ситуацию обрабатывает, фильтруя результат подзапроса.
51. scarabey2006 28 19.08.22 13:07 Сейчас в теме
(50) Надо искать дальше где оптимизировать можно (
sapervodichka; +1 Ответить
54. sapervodichka 6697 02.09.22 12:55 Сейчас в теме
В 1С ошибку приняли к исправлению
Прикрепленные файлы:
58. scarabey2006 28 01.12.22 10:33 Сейчас в теме
(54) в последнем релизе это уже исправлено ) даже в 17.23 видел, когда обновлялся
59. sapervodichka 6697 01.12.22 11:04 Сейчас в теме
(58) логично, я же им написал в августе, вот к осени и добавили исправление в релиз
55. Revachol 27.11.22 15:43 Сейчас в теме
А не правильнее было бы написать условие сразу так ("Организация = &Организация И ДоговорКонтрагента = &ДоговорКонтрагента И ОбъектРасчетов = &ОбъектРасчетов и ДокументРасчетов <> &Ссылка) исходя из структуры регистра?
sapervodichka; +1 Ответить
56. sapervodichka 6697 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 354 13.04.23 23:12 Сейчас в теме
Эх Ваши бы уста да в уши разработчикам... Мы этот блок тоже постоянно оптимизируем... Это просто клондайк... Достаточно ещё отметить, что при проведении ПТиУ проводится СФ, а в УХе в нагрузку ОФД, и при некоторых настройках может ещё и ВСКД проводиться (так называемая актуализация Авто) ... Эта ж жесть. Щас они хоть хешировать стали сам документ ОФД, и в случае если ключевые реквизиты его не изменяются, то он не перезаполняется и не перепроводится, а с ним и ВСКД... Но отсечение по хэшу всё равно долго работает. При восстановлении последовательности всё равно сильно сказывается. В итоге мы просто сравнивали XDTO ПТиУ до записи с XDTO записываемого с проведением документа и если они совпадали то вообще отсекали даже их алгоритмы, а вот если изменения были тогда уже их алгоритмы...
sapervodichka; +1 Ответить
62. sapervodichka 6697 13.04.23 23:21 Сейчас в теме
(61) а мы сделали проведение в несколько потоков разбив по связанным документам (200 - 400 тысяч документов в месяц, чтобы за пару дней проводились, а по умолчанию за 10 дней проводились)
63. check2 354 13.04.23 23:51 Сейчас в теме
(62) В одном из проектов было жёсткое требование к сохранению быстродействия проведения документов, и так же одной из частей было обновление УХи с 1.2 до 1.3 и как раз налетели на грабли с ОФД, которые в онлайне в 1.2 не проводились... Заказчик встал в позу. Пришлось сделать допроведение фоновым заданием. если документ проводился интерактивно и отключить совсем допроведение при восстановлении последовательности. Т.е. пользователь проводил только ПТУ, всё остальное проводилось фоном тут же. Всё что провелось с ошибками падало в регистр специальный и допроводилось вручную с предварительным разбором проблем. Тем самым мы сохранили полностью время проведения первички с 1.2 и не отрезали новый функционал.
fatman78; sapervodichka; +2 Ответить
64. sapervodichka 6697 13.04.23 23:56 Сейчас в теме
(63) Евгений, спасибо за комменты с идеями, мне и народу пригодится!
66. shura_k 11.08.23 16:25 Сейчас в теме
67. user2053365 15.02.24 16:37 Сейчас в теме
А провести документы только по интересующим регистрам не вариант? сам запрос до по логике 1совцев нормальный т.к. в соединении указаны поля соединения и по идее план запроса должен был построить выборку по этим полям, т.е. ограничение наложено в соединении. видимо платформа план запроса построила не верный.
68. sapervodichka 6697 15.02.24 18:16 Сейчас в теме
(67) Сама платформа не строит планы запроса, их строит СУБД, MS SQL и PostgreSQL строит по разному. В запросе не указан отбор поэтому быстрый индекс НЕ используется, в PostgresSQL строил неоптимальный план запроса. Вообщем 1С эту ситуацию зарегистрировали и исправили. Уже не актуально.
Оставьте свое сообщение