Демонические списки - пропажа процессорного времени ПриАктивизацииСтроки.
Всем доброго времени суток.
На форме размещен Динамический список:
Требуется установить отбор "Ссылка в СписокЗначений".
Для отбора элементов справочника по заданному списку я пробовал как добавлять СписокЗначений в качестве параметра в запрос динамического списка, так и устанавливать отбор через "ЭлементОтбораКомпоновкиДанных".
В обоих случаях все замечательно работает до тех самых пор пока количество элементов в СписокЗначений не перевалит примерно за сотню.
Если СписокЗначений толстеет, то сразу получаю тормоза при работе с указанным Динамическим списком - переходы между строк начинают занимать по 5 и более секунд.
Замер производительности показал, что узким местом является обработчик "ПриАктивизацииСтроки" данного ДинамическогоСписка, в котором вызывается серверная процедура, выполняющая несколько запросов к регистрам сведений по текущему элементу ДинамическогоСписка.
Получается ситуация:
То есть длительность выполнения процедуры на сервере остается прежней, но вот её вызов начинает занимать гораздо больше времени.
И я не понимаю почему. Куда пропадает 95% процессорного времени? Оно же не может пойти в пустоту?
Если Список значений очистить или закомментить обработчик "ПриАктивизацииСтроки" тормоза полностью проходят.
ЧЯДНТ?
==============================================
Как обычно, стоило спросить, и похоже, я сам нащупал суть проблемы.
Судя по всему замер производительности на сервере штука весьма условная. Данные, которые он отображает не имеют ничего общего с реальностью...
На форме размещен Динамический список:
Основная таблица - справочник.
Вид ключа - Авто.
Динамическое Считывание данных - да.
Вид ключа - Авто.
Динамическое Считывание данных - да.
Требуется установить отбор "Ссылка в СписокЗначений".
Для отбора элементов справочника по заданному списку я пробовал как добавлять СписокЗначений в качестве параметра в запрос динамического списка, так и устанавливать отбор через "ЭлементОтбораКомпоновкиДанных".
В обоих случаях все замечательно работает до тех самых пор пока количество элементов в СписокЗначений не перевалит примерно за сотню.
Если СписокЗначений толстеет, то сразу получаю тормоза при работе с указанным Динамическим списком - переходы между строк начинают занимать по 5 и более секунд.
Замер производительности показал, что узким местом является обработчик "ПриАктивизацииСтроки" данного ДинамическогоСписка, в котором вызывается серверная процедура, выполняющая несколько запросов к регистрам сведений по текущему элементу ДинамическогоСписка.
Получается ситуация:
&НаКлиенте
Процедура СписокПППриАктивизацииСтроки(Элемент)
ЗаполнитьРеквизитыТекущегоПП(Элемент.ТекущаяСтрока); //96% процессорного времени - 5 секунд
КонецПроцедуры
&НаСервере
Процедура ЗаполнитьРеквизитыТекущегоПП(ПотенциальныйПользователь)
// тут 3 запроса, каждый из которых занимает мене 1% процессорного времени - менее 0.5секунд.
КонецПроцедуры ПоказатьТо есть длительность выполнения процедуры на сервере остается прежней, но вот её вызов начинает занимать гораздо больше времени.
И я не понимаю почему. Куда пропадает 95% процессорного времени? Оно же не может пойти в пустоту?
Если Список значений очистить или закомментить обработчик "ПриАктивизацииСтроки" тормоза полностью проходят.
ЧЯДНТ?
==============================================
Как обычно, стоило спросить, и похоже, я сам нащупал суть проблемы.
Судя по всему замер производительности на сервере штука весьма условная. Данные, которые он отображает не имеют ничего общего с реальностью...
Найденные решения
(2) Да дело оказалось не в отборах вовсе.
Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.
Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.
Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Да дело оказалось не в отборах вовсе.
Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.
Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
Просто для некоторых элементов справочника процедура "ЗаполнитьРеквизитыТекущегоПП" работала значительно медленнее, чем для других. И СписокЗначений как раз и содержал большое количество таких элементов, поэтому при установке отбора наблюдались тормоза. Так совпало.
Меня ввел в заблуждение замер производительности, который отображает неправильное время выполнения кода внутри серверных процедур.
(4) да и использовать в этом обработчике стоит только серверные процедуры "&НаСервереБезКонтекста".
Хоть разработчики платформы и заявляют, что при использовании "&НаСервере" передаются только измененные данные формы, а данные динамических списков не передаются вовсе. По факту это не совсем так.
Ради интереса поместил в СписокЗначений 50000 элементов и передал их в параметр ДинамическогоСписка. Получил тормоза, время вызова сервера выросло с 0.08 секунд до 2.
Переписал механизм заполнения реквизитов формы при активизации строки используя только "&НаСервереБезКонтекста" - время вызова сервера 0.03 секунды =).
Хоть разработчики платформы и заявляют, что при использовании "&НаСервере" передаются только измененные данные формы, а данные динамических списков не передаются вовсе. По факту это не совсем так.
Ради интереса поместил в СписокЗначений 50000 элементов и передал их в параметр ДинамическогоСписка. Получил тормоза, время вызова сервера выросло с 0.08 секунд до 2.
Переписал механизм заполнения реквизитов формы при активизации строки используя только "&НаСервереБезКонтекста" - время вызова сервера 0.03 секунды =).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот