Проблемы производительности
«Хьюстон, у нас проблемы»
80 % - SOFT, 20 % - HARD
Объективная оценка проблем
Отсечь лишнее
Широкие возможности платформы 1С
ОШИБОЧНОЕ ИСПОЛЬЗОВАНИЕ
Основные тезисы
Ресурсоемкие операции SQL
Сортировка
Оптимизация запросов
Оптимизация запросов
Оптимизация запросов
Инструмент
Индексы
Индексы не бесплатны
Ограничение
Как создать
В конфигураторе
Не просто, а очень просто
Несколько вариантов
Индексация…всегда полезна?
…не всегда
одинаково полезно
Накладные расходы
Оптимизация кода 1С
Временные таблицы
Усложнять просто
…упрощать сложно
Запросы, сформированные платформой
Но все можно поправить 
Так делать «плохо»
Создаем #ВременнуюТаблицу
…и используем
Виртуальные таблицы Регистров
Можно, но не нужно
План «плохой»
План «ХОРОШИЙ»
Совсем плохо
«Милое деревце» плана запроса
Лучше так
Логика должна быть простой
Они бывают не только у автомобиля 
Исправление запросов
Приемы конфигурирования
Полезное
Полезное
2.91M

Проблемы производительности в 1С

1. Проблемы производительности

Разбор ошибок

2. «Хьюстон, у нас проблемы»

3. 80 % - SOFT, 20 % - HARD

Производительность • Не оптимальный код
конфигурации
ПО (Платформа 1С +
• Производительность
СУБД)
СУБД
• Производительность
процессора
• Объем доступного ОЗУ
Производительность
• Производительность
оборудования
дисковой подсистемы
• Производительность
сети

4. Объективная оценка проблем

APDEX

5. Отсечь лишнее

С чего начать?
Так ли они
необходимы?

6. Широкие возможности платформы 1С

СКД
Управляемый режим блокировок
Регламентные и фоновые задания
Функциональные опции
Режим разделения итогов
Возможность построения агрегатов
Итоги в регистрах сведений
Возможность индексирования + доп. Упорядочивание
Возможность работы при низком качестве канала связи (тонкий + web)
Использование Web/HTTP-сервисов
Отказоустойчивый кластер серверов
Многоплатформенность
Клиент-серверная архитектура (управляемая форма)
Полнотекстовый поиск

7. ОШИБОЧНОЕ ИСПОЛЬЗОВАНИЕ

Обращение к БД в цикле
• Тратится время на получение/передачу параметров, взаимодействие с SQL
Обращение к реквизиту объекта через объектную модель доступа
• Происходит чтение всего объекта, а требуется всего лишь получить код справочника
Неконтролируемая глубина рекурсивных вызовов
• Следует предусматривать ограничение глубины, иначе возможно падение кода
Излишнее злоупотребление таблицами значений взамен выборки
• Излишнее потребление памяти
Использование последовательных операций при возможности
распараллеливания
• Сервера стали много –ядерные/процессорные, пусть они не простаивают

8. Основные тезисы

Использовать транзакции только там где они необходимы
• Транзакция лишняя нагрузка на сервер
Использовать блокировки только там где они необходимы
• Нет смысла блокировать , если нет списания в «минус»
Использовать «запросную» технику чтения данных из ИБ
• Запрос получает только то что спросил разработчик
Использовать индексирование там где оно будет полезно
• Индекс даже если он есть, не всегда может быть использован

9. Ресурсоемкие операции SQL

Clustered Index Scan
Index Scan
Table Scan (более ~1500-2000 записей)
Время выполнения операторов ЛИНЕЙНО растет с ростом сканируемых объектов
Сортировка в запросе
Агрегирование
Не следует увлекаться, там где этого не требуется

10. Сортировка

Данные в базе SQL хранятся «беспорядочно»
Иногда порядок важен
Расплачиваемся потерей времени

11. Оптимизация запросов

12. Оптимизация запросов

Время выполнения 5 553 мс

13. Оптимизация запросов

Время выполнения 3 658 мс
Проигрыш = 5,6/3,7 = 1,5 раза !!!
Записи в базе SQL хранятся неупорядоченными

14. Инструмент

SQL Sentry Plan Explorer

15. Индексы

Кластерный – один на таблицу
Некластерный - много
Можно создать «руками» - реструктуризация базы их удалит,
и это является нарушением лицензионного соглашения 1С

16. Индексы не бесплатны

Индексы занимают место
Замедляют операции удаления,
вставки, обновления

17. Ограничение


Индекс может быть создан на основании нескольких полей. В этом
случае существует ограничение – длина ключа индекса не должна превышать
900 байтов и не более 16 ключевых столбцов. На практике это означает что
при создании индекса, включающего более 16 полей, индекс усекается. Это
может оказать влияние на производительность при количестве субконто
составного типа более 4х
Чрезмерная фрагментация создает проблемы для больших операций вводавывода. Фрагментация не должна превышать 25%. От снижения
фрагментации индексов могут выиграть операции сканирования больших
диапазонов данных. Для этого рекомендуется выполнять периодическую
дефрагментацию индексов. Обратите внимание, что при дефрагментации
индексов (по умолчанию) автоматически обновляется статистика.
Смотреть степень фрагментированности индексов можно штатными
средствами СУБД.

18. Как создать


Существуют следующие способы создания и/или изменения индексов:
– изменение порядка следования измерений объектов метаданных;
– использование свойства Индексировать у реквизитов объектов метаданных;
– включение реквизитов объектов метаданных в критерий отбора.

19. В конфигураторе


Существуют следующие способы создания и/или изменения индексов:
– при установке свойств измерений Ведущее и Индексировать создается
дополнительный индекс;

20. Не просто, а очень просто

21. Несколько вариантов


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

22. Индексация…всегда полезна?

ИНДЕКСИРОВАТЬ ПО
НЕ ВСЕГДА ПОЛЕЗНО, ИНОГДА ВРЕДНО

23. …не всегда

ИНДЕКСИРОВАТЬ ПО
Время выполнения запроса
может возрасти

24. одинаково полезно

ИНДЕКСИРОВАТЬ ПО
Время выполнения запроса
может возрасти

25. Накладные расходы

ИНДЕКСИРОВАТЬ ПО
Создание индекса увеличило время
в 2,5 раза

26. Оптимизация кода 1С

http://helpdesk.efko.ru/tracks.php?id=IT257838
Оптимизация кода 1С
ПРОБЛЕМА: за час прогрузилось 13600 строк файла из 76194 ===> ~5,5 часов
ИНДЕКСИРОВАНИЕ
доступно для ТЗ
5,5 часов – против 15 минут, есть смысл пользоваться ;)

27. Временные таблицы

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

28. Усложнять просто

Использование выражений в отборах
Какая разница во времени
выполнения запросов?

29. …упрощать сложно

Падение во времени не «РАЗЫ»,
а 2 порядка – 300 раз!!!

30. Запросы, сформированные платформой

Используются вычисляемые выражения

31. Но все можно поправить 

Но все можно поправить ☺
Выбираем только то, что нужно
•ВЫБРАТЬ * ИЗ Документ.РеализацияТоваров
При работе в авт. режиме блокировок при использовании конструкции ДЛЯ ИЗМЕНЕНИЯ надо указывать какие таблицы блокировать, если в
запросе участвует более одной таблицы
Условия в запросе и индексы в базе должны соответствовать
•Порядок измерений в регистрах
При работе с виртуальными таблицами нужно использовать параметры виртуальных таблиц, а не выносить условия в секцию ГДЕ
•РегистрНакопления.ТоварныеЗапасы.ОстаткиИОбороты(&ДатаНач, &ДатаКон, День, Движения, Склад = &Склад)
Не применять избыточное агрегирование
•ВЫБРАТЬ
•ТоварныеЗапасыОбороты.Склад, СУММА(ТоварныеЗапасыОбороты.КоличествоОборот) КАК КоличествоОборот
•ИЗ
•РегистрНакопления.ТоварныеЗапасы.Обороты КАК ТоварныеЗапасыОбороты
•СГРУППИРОВАТЬ ПО
•ТоварныеЗапасыОбороты.Склад
При соединении таблиц все условия и параметры, относящиеся к полям этих таблиц, ставить в условия соединения или пользоваться временными
таблицами, а не оставлять их до секции ГДЕ
Не использовать подзапросы в условии соединения и в секции ГДЕ, лучше использовать временные таблицы
Не соединять виртуальные таблицы с реальными, а также виртуальные с виртуальными. Правильно использовать временные таблицы и их
соединять.

32. Так делать «плохо»


Соединения с вложенными запросами

33. Создаем #ВременнуюТаблицу


Соединения с вложенными запросами
– вместо вложенных запросов в соединениях ВСЕГДА нужно использовать
временные таблицы. При этом их необходимо проиндексировать по полям,
участвующим в условии соединения

34. …и используем

Оптимизатор сразу оценивает
количество записей, план оптимальный

35. Виртуальные таблицы Регистров

Виртуальные таблицы регистров
Оптимизатор сразу оценивает
количество записей, план оптимальный

36. Можно, но не нужно

Обращение Реквизит.Ссылка
ЗАЧЕМ ???!!!

37. План «плохой»

Обращение Реквизит.Ссылка
Лишнее соединение

38. План «ХОРОШИЙ»

Неправильно
Правильно:

39. Совсем плохо

Неправильно
Правильно:

40. «Милое деревце» плана запроса

10 регистраторов у РН «Товарные запасы»

41. Лучше так

ВЫБРАТЬ
ВЫРАЗИТЬ(ТоварыНаСкладах.Регистратор КАК Документ.ПоступлениеТоваров).Номер,
ВЫРАЗИТЬ(ТоварыНаСкладах.Регистратор КАК Документ.ПоступлениеТоваров).Дата,
ТоварыНаСкладах.Количество,
ТоварыНаСкладах.Поставщик
ИЗ
РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
ГДЕ
ТоварыНаСкладах.Регистратор ССЫЛКА Документ.ПоступлениеТоваров
Необходимо использовать приведение типов

42. Логика должна быть простой

Логические условия в соединении, отборе
Сканирование индекса
Поиск по индексу

43. Они бывают не только у автомобиля 

Они бывают не только у автомобиля ☺
АГРЕГАТЫ регистров накопления
Оборотные регистры накопления
http://1sprogress.ru/anatomiya-platformy-chto-takoe-agregaty-i-zachem-oni-nuzhny.html

44. Исправление запросов

Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в
секции ПО запроса, а также в секции ГДЕ
Не рекомендуется использовать условие «Не равно», особенно если на «Не равно»
сравниваются ссылки
Избегать запросов к пустым таблицам в режиме автоматического управления
блокировками 1С
Аккуратно пользоваться разыменованием (получение данных «через точку»)
Не использовать конструкцию Ссылка.Ссылка
Понимать как запрос может быть изменен при использовании RLS
ОБЪЕДИНИТЬ ВСЕ \ ОБЪЕДИНИТЬ

45. Приемы конфигурирования

Использование констант не по назначению
•Лишние блокировки, страдает параллельность работы пользователей
Использование авторегистрации в последовательности и сдвиг границы при проведении
•Лишние блокировки, страдает параллельность работы пользователей
Использование скобок Попытк…Исключение внутри транзакции
•Откат транзакции с ошибкой
Использовать вложенные транзакции, явно и неявно, например вызов из процедур документа проведение других документов, запись элементов
справочников и др.
Использование запросов в цикле, в том числе и через объектную модель
Неявно использовать запросы в цикле (ПриВыводеСтроки)
В транзакции ( в т.ч. Проведения документа) получать данные не из регистров, а из других документов.
Открывать модальные формы внутри транзакции
Вызывать ЭтотОбъект.Записать() внутри транзакции записи объекта, например, из процедуры ОбработкаПроведения.
Вызывать обращение через СОМ-соединение к другой базе внутри транзакции
В формах, в которых динамический список формируется через произвольный запрос, чрезмерно усложнять запрос

46. Полезное

http://buh.ru/books/detail.php?ID=42721
http://buh.ru/books/detail.php?ID=42696
http://www.ozon.ru/context/detail/id/24931129/

47. Полезное


Руководство по проектированию индексов (https://msdn.microsoft.com/ruru/library/jj835095(v=sql.120).aspx)
Оптимизация производительности (www.gilev.ru)
Сообщество разработчиков (www.infostart.ru)
Курсы по 1С (http://xn----1-bedvffifm4g.xn--p1ai/)
Спасибо за внимание.
English     Русский Правила