Формирование заказов по потребностям скорость выполнения
Закупки ->Заказы поставщикам ->Создать->По потребностям
формирование заказов по потребностям шаг1 из 5
выбираю склад и номенклатуру - не много - порядка 80000
нажимаю далее - попадаю на шаг 2 и снова нажимаю далее
Можно пойти покурить
скорость выполнения очень маленькая , после выполнения трассировки по времени исполнения
обнаружил приличную задержку в обработке {ОбеспечениеПотребностей} модуль мененджера
Посмотрел в профайлере SQL , запрос конечно дико большой
Какие шаги можно предпринять для уменьшения времени ?
формирование заказов по потребностям шаг1 из 5
выбираю склад и номенклатуру - не много - порядка 80000
нажимаю далее - попадаю на шаг 2 и снова нажимаю далее
Можно пойти покурить
скорость выполнения очень маленькая , после выполнения трассировки по времени исполнения
обнаружил приличную задержку в обработке {ОбеспечениеПотребностей} модуль мененджера
Функция ТаблицаЗапасы(Отбор, ТипОтбора, ТаблицаСпособовОбеспечения = Неопределено) Экспорт
...
Сообщить ("Beg "+ТекущаяДата() ); // поставил для
Таблица = Запрос.Выполнить().Выгрузить();
Сообщить ("End "+ТекущаяДата() ); // порядка 8 минут
Посмотрел в профайлере SQL , запрос конечно дико большой
Какие шаги можно предпринять для уменьшения времени ?
По теме из базы знаний
- 1С:Хлебобулочное и кондитерское производство. Модуль для 1С:ERP и 1С:КА
- 1С:Управление строительной организацией. 1С:ERP Управление строительной организацией 2
- Как кропотливая работа оказалась эффективнее энергичной атаки
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
- ФОРО: Физические основы развития организации
Найденные решения
(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 минут , это конечно уже хорошо.
Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - о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)
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - о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 минут , это конечно уже хорошо.
Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
Оборудование менять при обнаружении криво написанных запросов затратно. Хотя это неплохой способ нагреть руки , объяснив руководству необходимость смены оборудования, и получив от фирмы поставщика оборудования - о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 минут , это конечно уже хорошо.
Но сам запрос убийственно большой. Программисты пишущие большие запросы наверняка знают - первым запросом надо отсечь максимально большое количество лишних записей которые не нужны для расчета, и только следующем запросе работать с усеченным набором записей, если все лепить в один запрос - скорости падают.
Например , допустим имеется таблица операций порядка 100 миллионов записей, поле дата имеет индекс.
нужно сделать некоторые расчеты за день.
Если первым запросом выбрать данные за 1 день , и только в следующем запросе SQL , либо в следующих делать расчет - подав от первого запроса на вход данные, скорость будет в разы выше , чем если все расчеты лепить в одном запросе.
Проверено на практике.
нужно сделать некоторые расчеты за день.
Если первым запросом выбрать данные за 1 день , и только в следующем запросе SQL , либо в следующих делать расчет - подав от первого запроса на вход данные, скорость будет в разы выше , чем если все расчеты лепить в одном запросе.
Проверено на практике.
(4) действительно много зависит от состояния базы, даже скорость формирования автозаказа является маркером её производительности. Как только просела - значит есть проблема с регламентными заданиями обслуживания базы.
При написании автозаказа (выложено на ) запрос оптимизировался декомпозицией на подзадачи с применением временных таблиц. Первоначальный вариант был очень медленным. Как сделали много временных таблиц так подняли производительность в 10 раз.
При написании автозаказа (выложено на ) запрос оптимизировался декомпозицией на подзадачи с применением временных таблиц. Первоначальный вариант был очень медленным. Как сделали много временных таблиц так подняли производительность в 10 раз.
(5)
Вот что интересно , где то натыкался что при сдаче экзаменов по 1С , правильным считается "лепить" все в один запрос , именно лепить, другого слова не подбирается.
Считается дурным тоном дробить - на разумные две три выборки.
Видимо для красоты и солидности втюхивают все в один большой длинный запрос :-)
Если оперировать на пару тыс записей , то разницы конечно нет. Но при росте базы , начнутся проблемы.
Вот что интересно , где то натыкался что при сдаче экзаменов по 1С , правильным считается "лепить" все в один запрос , именно лепить, другого слова не подбирается.
Считается дурным тоном дробить - на разумные две три выборки.
Видимо для красоты и солидности втюхивают все в один большой длинный запрос :-)
Если оперировать на пару тыс записей , то разницы конечно нет. Но при росте базы , начнутся проблемы.
(6) очень большое количество строк и много-критериальные (большое количество колонок) обрабатываю одним запросом - все очень быстро выполняется (только очень много подзапросов и временных таблиц в запросах), считаю что очень много в производительности зависит от обслуживания базы.
Проблема была серьезная - только вложенные запросы и сложные соединения.
Думаю если проще написать запрос, то будет работать быстро. Да вот пример там текст в модуле .
Проблема была серьезная - только вложенные запросы и сложные соединения.
Думаю если проще написать запрос, то будет работать быстро. Да вот пример там текст в модуле .
(7) Если в базе 700 - 900 миллионов записей скажем это операции за каждый день с приращением в день 50-100 тыс записей,
попробуйте два варианта:
вариант 1) одним большим запросом выбирать всю кучу сразу, при этом в запросе будет тяжелый расчет для одного дня , где надо еще цеплять с десяток - два других таблиц.
вариант 2) первый запрос выбирает во времянку - скажем только один день состоящий скажем из 50 тыс записей в этом запросе выбираем только из одной таблицы по индексированому полю, далее получив времянку , вторым запросом делаем достаточно сложные и тяжелые обработки подцепив пару десятков справочников.
и Вы увидите разницу межу тем как , сразу что то считать соединяя еще кучу таблиц в один запрос, или обрабатывать уже короткую выборку.
Но если вы говорите о основной исторической таблице на 5-10 тыс строк может 100, то разница вероятно будет невелика.
попробуйте два варианта:
вариант 1) одним большим запросом выбирать всю кучу сразу, при этом в запросе будет тяжелый расчет для одного дня , где надо еще цеплять с десяток - два других таблиц.
вариант 2) первый запрос выбирает во времянку - скажем только один день состоящий скажем из 50 тыс записей в этом запросе выбираем только из одной таблицы по индексированому полю, далее получив времянку , вторым запросом делаем достаточно сложные и тяжелые обработки подцепив пару десятков справочников.
и Вы увидите разницу межу тем как , сразу что то считать соединяя еще кучу таблиц в один запрос, или обрабатывать уже короткую выборку.
Но если вы говорите о основной исторической таблице на 5-10 тыс строк может 100, то разница вероятно будет невелика.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот