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

1. yurazyuraz 22.03.18 09:17 Сейчас в теме
Закупки ->Заказы поставщикам ->Создать->По потребностям

формирование заказов по потребностям шаг1 из 5
выбираю склад и номенклатуру - не много - порядка 80000
нажимаю далее - попадаю на шаг 2 и снова нажимаю далее

Можно пойти покурить

скорость выполнения очень маленькая , после выполнения трассировки по времени исполнения
обнаружил приличную задержку в обработке {ОбеспечениеПотребностей} модуль мененджера

Функция ТаблицаЗапасы(Отбор, ТипОтбора, ТаблицаСпособовОбеспечения = Неопределено) Экспорт
...
	Сообщить ("Beg "+ТекущаяДата() ); // поставил для 
	Таблица = Запрос.Выполнить().Выгрузить(); 
	Сообщить ("End "+ТекущаяДата() ); // порядка 8 минут 


Посмотрел в профайлере SQL , запрос конечно дико большой

Какие шаги можно предпринять для уменьшения времени ?
По теме из базы знаний
Найденные решения
3. yurazyuraz 22.03.18 10:15 Сейчас в теме
(2)
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - оtкат за хороший заказ, ИТ сфера хороша для подобных схем.

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

В другой задаче ( не 1с платформа) имеется порядка 100 миллионов записей , запрос проходит порядка 5 секунд. Правда он состоит из 3 SQL запросов
вместо одного, если соединяю в один - не получаю 5 секунд - получаю несколько минут.


А вот с оптимизацией поиграл.
После того как провел реиндексацию на SQL сервере , по всем индексам , проанализировал запрос и создал прямо на SQL сервере индексы по полям которые принимают участие в поиске , скорость запроса увеличилась в ТРИ РАЗА!

Beg 22.03.2018 10:10:14
End 22.03.2018 10:12:52

Получаю порядка 2:38 минут , это конечно уже хорошо.

Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
Остальные ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. МихаилМ 22.03.18 09:56 Сейчас в теме
установить более производительное оборудование либо нанять специалистов для оптимизации оборудования и ПО
3. yurazyuraz 22.03.18 10:15 Сейчас в теме
(2)
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - оtкат за хороший заказ, ИТ сфера хороша для подобных схем.

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

В другой задаче ( не 1с платформа) имеется порядка 100 миллионов записей , запрос проходит порядка 5 секунд. Правда он состоит из 3 SQL запросов
вместо одного, если соединяю в один - не получаю 5 секунд - получаю несколько минут.


А вот с оптимизацией поиграл.
После того как провел реиндексацию на SQL сервере , по всем индексам , проанализировал запрос и создал прямо на SQL сервере индексы по полям которые принимают участие в поиске , скорость запроса увеличилась в ТРИ РАЗА!

Beg 22.03.2018 10:10:14
End 22.03.2018 10:12:52

Получаю порядка 2:38 минут , это конечно уже хорошо.

Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
4. yurazyuraz 22.03.18 10:28 Сейчас в теме
Например , допустим имеется таблица операций порядка 100 миллионов записей, поле дата имеет индекс.
нужно сделать некоторые расчеты за день.

Если первым запросом выбрать данные за 1 день , и только в следующем запросе SQL , либо в следующих делать расчет - подав от первого запроса на вход данные, скорость будет в разы выше , чем если все расчеты лепить в одном запросе.
Проверено на практике.
5. ksnik 578 24.03.18 12:53 Сейчас в теме
(4) действительно много зависит от состояния базы, даже скорость формирования автозаказа является маркером её производительности. Как только просела - значит есть проблема с регламентными заданиями обслуживания базы.

При написании автозаказа (выложено на infostart) запрос оптимизировался декомпозицией на подзадачи с применением временных таблиц. Первоначальный вариант был очень медленным. Как сделали много временных таблиц так подняли производительность в 10 раз.
6. yurazyuraz 27.03.18 06:21 Сейчас в теме
(5)

Вот что интересно , где то натыкался что при сдаче экзаменов по 1С , правильным считается "лепить" все в один запрос , именно лепить, другого слова не подбирается.
Считается дурным тоном дробить - на разумные две три выборки.
Видимо для красоты и солидности втюхивают все в один большой длинный запрос :-)
Если оперировать на пару тыс записей , то разницы конечно нет. Но при росте базы , начнутся проблемы.
7. ksnik 578 27.03.18 10:08 Сейчас в теме
(6) очень большое количество строк и много-критериальные (большое количество колонок) обрабатываю одним запросом - все очень быстро выполняется (только очень много подзапросов и временных таблиц в запросах), считаю что очень много в производительности зависит от обслуживания базы.
Проблема была серьезная - только вложенные запросы и сложные соединения.
Думаю если проще написать запрос, то будет работать быстро. Да вот пример там текст в модуле https://infostart.ru/public/156873/.
8. yurazyuraz 04.04.18 13:59 Сейчас в теме
(7) Если в базе 700 - 900 миллионов записей скажем это операции за каждый день с приращением в день 50-100 тыс записей,

попробуйте два варианта:


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


вариант 2) первый запрос выбирает во времянку - скажем только один день состоящий скажем из 50 тыс записей в этом запросе выбираем только из одной таблицы по индексированому полю, далее получив времянку , вторым запросом делаем достаточно сложные и тяжелые обработки подцепив пару десятков справочников.

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

Но если вы говорите о основной исторической таблице на 5-10 тыс строк может 100, то разница вероятно будет невелика.
9. ksnik 578 04.04.18 14:33 Сейчас в теме
(8) yurazyuraz, в 4 порции (захода) создается 50-100 тысяч результатных строк (номенклатура * подразделение).
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)