То ли после обновления платформы, то ли база увеличилась или может быть сам запрос усложнился, а может все вместе, но отчет стал сильно тормозить. Конфигурация УТ 11.1. Платформа 8.3.27.1936, серверная версия.
Пробовал оптимизировать запрос в консоли. В консоли запрос отрабатывает примерно за 5 секунд, а вот тот же самый запрос с теми же параметрами в отчете на СКД выполняется примерно за 40 секунд.
Попутно встал вопрос как делать замер производительности отчетов на СКД. Как я уже сказал, отчет выполняется примерно 40 секунд, а в конфигураторе замер производительности показывает примерно те же 5 секунд.
Если смотреть в процентном соотношении, то основная часть времени приходится на команду
СкомпоноватьРезультат(РежимКомпоновкиРезультата.Авто);
из процедуры общей формы отчета СформироватьНепосредственно()
Т.к. версия серверная, то параметр РежимКомпоновкиРезультата.Авто запускает выполнение компоновки в фоне. И вот это время в фоне, как я понял, не считается в замере производительности. Пока я шел по отладчику, в поисках того места, где же происходит зависание, фоновое задание уже завершилось и получилось что замер производительности показал ни больше ни меньше - ровно столько, сколько выполнялись все команды без учета фонового выполнения.
Если прописать:
СкомпоноватьРезультат(РежимКомпоновкиРезультата.Непосредственно);
то тогда уже в замере производительности будет показано то время, которое уходит на выполнение отчета.
Более удобным показался вариант с использованием подсистемы Оценка производительности. APDEX я не использовал для анализа, просто добавил в справочник Ключевые операции элемент с именем "Внешний отчет" и в общей форме отчета добавил две команды:
&НаКлиенте Процедура ОтчетСкомпоноватьРезультат(Команда) ВремяНачала = ОценкаПроизводительностиКлиентСервер.НачатьЗамерВремени("Внешний отчет"); // ХА ОчиститьСообщения(); Сформировать(); ОценкаПроизводительностиКлиентСервер.ЗакончитьЗамерВремени("Внешний отчет",ВремяНачала); // ХА КонецПроцедуры
Тогда при выполнении отчета в регистр сведений "Замеры времени" записывается время выполнения отчета. Правда если остановиться в отладчике, то время будет продолжать считаться, поэтому этот вариант можно использовать без остановки в отладчике.
Но сейчас не об этом. Возвращаемся непосредственно к отчету. Получается, что потеря производительности происходит не в самом запросе, а при компоновке. Стал пробовать удалять из настроек отчета группировки, сортировки, отборы, поля, условное оформление. И вот на полях нашел различие в скорости формирования отчета. Запрос достаточно сложный и в одном из пакетов у меня левым соединением из регистра сведений получается поле НомерСклада. Это поле имеет тип значения СправочникСсылка.ЗначенияСвойствОбъектов. Дак вот если я в отчете выбираю это поле, то производительность резко падает.
Думал, что может быть в модуле менеджера что-то есть в процедуре <ОбработкаПолученияПредставления>, что могло бы замедлить вывод отчета. Но нет, там нет такой процедуры. Тогда получается, что скорее всего запрос преобразуется платформой к другому виду. Для того, чтобы понять какой в конечном итоге получился запрос, прописал в модуле отчета такой код:
Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) Настройки = КомпоновщикНастроек.ПолучитьНастройки(); КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных; МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных,Настройки); Запрос = МакетКомпоновки.НаборыДанных.Получить(0).Запрос; КонецПроцедуры
Сравнил два запроса - один с выбором поля НомерСклада(работает медленно), другой без этого поля(работает быстро).
Какой то существенной разницы в запросах не нашел. Увидел только то, что в медленном запросе дополнительно выбираются поля:
Рез_БезДопХар.НомерСклада, ПРЕДСТАВЛЕНИЕССЫЛКИ(Рез_БезДопХар.НомерСклада),
Решил все таки попробовать в запросе выбирать не ссылку на справочник ЗначенияСвойствОбъектов, а просто наименование. И сработало. Отчет стал работать быстрее.
Отправить комментарий