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

10.04.23

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

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

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

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

&НаКлиенте
Процедура Тыц(Команда)
    ТыцНаСервере();
КонецПроцедуры

&НаСервере
Процедура ТыцНаСервере()
    Для Счетчик = 1 По 50 Цикл
        Метод1();
        Метод2();
    КонецЦикла;
КонецПроцедуры

&НаСервере
Процедура Метод1()
    //Какой-то код
КонецПроцедуры

&НаСервере
Процедура Метод2()
    //Какой-то код
КонецПроцедуры

Два алгоритма, которые нужно сравнить, помещаем в Метод1 и Метод2. Потом запускаем Замер производительности. Когда открывается окно с результатами, ставим там галку Для вызова процедур и функций включать время выполнения (1). Ещё установим сортировку по строкам модуля (2) и вот они, наши процедуры, как на ладони (3):

 

 

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

Для Счетчик = 1 По 50 Цикл
    Метод1();
    Метод2();
КонецЦикла;

Собственно, это всё. На скрине выше результат, когда процедуры идентичны. Так что метод, в принципе, работает. Результат не то, чтобы абсолютно одинаковый, но почти. Будем считать, что погрешность где-то в районе процента – это вполне нормально. 

 
Процедуры идентичны

 

Дальше для иллюстрации приведу несколько типичных ситуаций, когда все всё понимают, но не хотят говорить. Одно дело просто утверждение, другое — цифры, которые можно потрогать руками.

Запросы одинаковые, но в одном случае реквизит берётся из выборки, а в другом – из ссылки. Сравните: ИНН = Выборка.КонтрагентИНН и ИНН = Выборка.Контрагент.ИНН. 31% и 64% соответственно. Это потому, что чудес не бывает. Платформе здесь (неявно) приходится делать обращение к БД. В общем, повод лишний раз убедиться: запрос в цикле – это плохо

 
Запрос в цикле 

 

Соединения влияют на быстродействие, 54% когда в запросе есть соединение против 39%, когда нет.

 
Соединение (простое)

 

Кстати, совсем банально (когда я писал статью, долго думал, куда поставить это самое «Совсем банально»: здесь, в общем-то, многое банально). В конечном счёте запросы к БД всё равно будут одинаковыми, поэтому явное это соединение или нет, разницы почти никакой, 45% и 46%:

 
Соединения неявное и явное

   

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

Однако всё меняется, когда в запросе (причём, не только в соединении!) используется какая-то сложная функция и движок не может использовать существующие индексы. Если вам интересны подробности, можно поинтересоваться у Гугла и Яндекса насчёт, примерно, такого: «сканирование таблиц при соединении в запросе sql». Например, посмотрите здесь: https://its.1c.ru/db/metod8dev/content/5842/hdoc

Тут становится совсем грустно, поэтому нужно крепко думать:

 
Соединение по неиндексированному полю 

 

Замер производительности Отладка

См. также

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

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

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

20.11.2023    5373    ivanov660    4    

61

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

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

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

15.11.2023    3496    a.doroshkevich    20    

64

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

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

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

11.10.2023    13377    skovpin_sa    14    

82

Как эффективно настроить autovacuum в Postgres для 1С

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

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4169    1CUnlimited    5    

48

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

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

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

20.06.2023    10543    Филин    37    

101
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Alxby 1116 10.04.23 14:13 Сейчас в теме
Казалось бы, элементарно - а эффективно! Заслуженный плюс.
3. vkrivov@yandex.ru 40 10.04.23 19:07 Сейчас в теме
(1)
Спасибо!
2. mixperm 67 10.04.23 14:51 Сейчас в теме
Ну раз такая банальность для школьников, тогда надо еще добавить левые, правые, полные, внутренние соединения, вложенные запросы и временные таблицы, условия в соединении или в условиях, без дублей и без повторяющихся и тому подобное из курса оптимизации)
5. vkrivov@yandex.ru 40 10.04.23 19:14 Сейчас в теме
(2)
Ну раз такая банальность для школьников, тогда надо еще добавить левые, правые, полные, внутренние соединения, вложенные запросы и временные таблицы, условия в соединении или в условиях, без дублей и без повторяющихся и тому подобное из курса оптимизации)

Я навскидку подобрал то, что первое в голову пришло. Если подробно разбирать всё, что Вы сказали, то это будет именно что курс по оптимизации ))
4. vkrivov@yandex.ru 40 10.04.23 19:08 Сейчас в теме
Запросы ведь очень тяжёлая штука. Даже небольшие ошибки в логике сразу заметны. Поэтому и примеры про запросы.
6. MegasXXX 2 17.04.23 11:49 Сейчас в теме
Очень простая статья, прям для совсем начинающих.

Я бы добавил про составные типы
Что то типа:
РеализацияТоваров.Сделка.АдресДоставки
Или через левое соединение РТУ с Заказом и уже из заказа выбираем АдресДоставки
7. triviumfan 87 17.04.23 12:03 Сейчас в теме
Смекалисто. Но думаю, что такой способ, не всегда применим, причина - кеширование на уровне сервера приложений и СУБД.
8. rwn_driver 8 18.04.23 10:10 Сейчас в теме
(7) Добрый день.
Именно против кэширования используется цикл, об этом в самом начале написано, читайте внимательней.
9. rwn_driver 8 18.04.23 10:11 Сейчас в теме
А если в последнем запросе последнего примера сделать соединение не по наименованию контрагента, а по ссылке (Документ.Контрагент = Контрагенты.Ссылка), быстродействие изменится?
10. vkrivov@yandex.ru 40 19.04.23 09:54 Сейчас в теме
(9)
Конечно изменится. Поле Ссылка ведь индексируется.
Что такое соединение? Есть две таблицы, и описана функция связи. Сначала нужно выполнить декартово умножение – составить пары всех записей из обеих таблиц (всё со всем) – а затем к каждой паре применить функцию связи. Если функция выполняется, пару берём. То есть нужно обработать ВСЕ связи.
Например, таблица контрагентов, это порядка сотен записей, таблица документов РТУ – сотен тысяч или даже миллионов. Если даже брать по минимуму, то это будет 100 × 100`000 = 10`000`000 связей. И каждую нужно проверить! Чтобы облегчить себе жизнь, база использует индексы. Если их нет (у поля НаименованиеПолное их нет), то приходится всё делать руками.
11. rwn_driver 8 20.04.23 13:31 Сейчас в теме
(10)Именно это я и имел ввиду, когда писал про переделку запроса, поскольку "Документ.Контрагент.НаименованиеПолное = Контрагенты.НаименованиеПолное" мало того, что не индексируется, ещё и подразумевает (скрытое) левое соединение со справочником "Контрагенты"... Или Вы просто привели пример неоптимальности чтобы показать разницу быстродействия?
12. vkrivov@yandex.ru 40 23.04.23 09:51 Сейчас в теме
(11)
Вы правы, пример как раз для этого.
Единственно, на практике я бы с осторожностью называл какое-то соединение неоптимальным. А вдруг по другому никак? Вдруг, логика очень хитрая? Просто нужно представлять, что происходит под капотом и принимать решение осознано.
13. svilsa 11 26.04.23 12:57 Сейчас в теме
Очень круто!
14. vkrivov@yandex.ru 40 28.04.23 15:06 Сейчас в теме
(13)
Спасибо! ))
Sergik_D; +1 Ответить
15. Altone1976 01.09.23 09:57 Сейчас в теме
а давайте возьмём не запросы для джунов , а реальные отчёты за 100тыс строк
теперь запустим их 100500 раз через цикл

и что же мы увидим :? да ничего! абсолютно никакого смысла. если у тебя и так максимально оптимизированный запрос , ничего не даст его повторение.

смысл в статье - а давайте прописные истины проверим : ой они работают...
Оставьте свое сообщение