Skip to content

Влияние признака «динамическое считывание данных» на скорость работы динамических списков

Влияние признака «динамическое считывание данных» на скорость работы динамических списков.

В управляемом приложении элемент формы типа «СправочникСписок» (а так же «ДокументСписок», «РегистрСведенийСписок» и др.) получил долгожданное развитие в виде элемента формы «ДинамическийСписок». Получился достаточно удобный инструмент, однако, несмотря на простоту в настройке и применении, он достаточно «капризен» и способен потреблять чрезмерное количество ресурсов (преимущественно сервера баз данных), порой существенно замедляя работу системы.

Оценим влияние неоптимальных настроек динамического списка на производительность системы, рассмотрев пример из «реальной жизни». Имеем функциональный инструмент в интерфейсе которого используется динамический список

Источником данных для динамического списка является запрос:

Помимо неоптимальной реализации самого запроса, разработчик не указал «основную таблицу» и не включил признак «динамическое считывание данных» (в настройках динамического списка), хотя очевидно, какая таблица в запросе является основной, а ее (таблицы) выбор позволит включить «динамическое считывание данных».

Что бы оценить последствия допущенных выше ошибок, проанализируем объем и скорость передачи информации между пользовательским компьютером и сервером приложения при обновлении данных в динамическом списке (что в свою очередь позволит понять как быстро обновляется информация в списке).

Для этого необходимо:

1. настроить монитор показателей производительности 1С:


2. в пользовательском режиме (режиме 1С:Предприятия) установить курсор на одной из строк динамического списка;

3. нажать на кнопку командной панели динамического списка «Обновить» (или F5).

Выполнив вышеперечисленные действия, получаем следующие результаты замеров:

Время ожидания между нажатием на кнопку «Обновить» и завершением процедуры обновления динамического списка составляет 21,66 секунд. Во время этой операции с клиента (компьютера пользователя) на сервер приложения отправлено 622 байта, а клиент получил от сервера приложения 24,710 байт. Очевидно, что трудозатраты в 21,66 секунд на передачу такого объема информации это невероятно долго, при условии что наши действия выполняются на обособленном оборудовании и его (оборудования) загрузка не может влиять на скорость выполнения операции (оборудование используется только нами), а характеристики оборудования более чем достаточны для достижения высокой производительности выполняемой операции. Т.к. объем и скорость клиент-серверного обмена не может быть причиной низкой скорости выполнения операции – проблемы скорее всего на стороне серверов 1С и/или БД.

Начнем расследование с анализа трудозатрат системы управления базами данных (далее СУБД) на выполнение запросов для получения и вывода информации в динамический список. Для этого включим сбор информации об исполняемых запросах (во время обновления динамического списка) на стороне СУБД:

колонка duration содержит информацию о времени выполнения запросов в миллисекундах

Уже без подробного анализа полного списка выполненных запросов, видно, что львиную долю трудозатрат при обновлении динамического списка занимает выполнение запросов (чуть больше 23 секунд занимает выполнение первых 7 запросов). Заставляет удивиться и количество запросов, которые исполняются СУБД при выполнении на первый взгляд простой операции: аж ~375 запросов (небольшая часть из них не связанна с обновлением динамического списка, а представляет собой регламентные операции, выполняемые технологической платформой).

Давайте посмотрим на самый долгий запрос, выполнявшийся почти 13 секунд и потребовавший выполнения ~180 тыс. логических чтениях информации из БД:

Это один из запросов получающий информацию из документа «киЗаписьРеестраРабот», для вывода в динамическом списке.

Как мы видим, извлекается о 1000 документах (об этом говорит конструкция «SELECT TOP 1000»). Ситуация в которой пользователь будет просматривать в интерфейсе формы весь список из 1000 документов может возникать крайне редко, скорее уж он будет пользоваться отбором или поиском, для получения необходимой информации. Более того, пока пользователь будет вдумчиво просматривать такой объем информации, она (информация) может потерять актуальность (реквизиты документов могут быть изменены другими пользователями). На мой взгляд такая большая выборка не имеет смысла, куда эффективнее считывать из базы данных информацию чаще, но в меньшем количестве (информацию о десятках документов) – так полученная информация будет более актуальной.

В ситуации, когда не включено «Динамическое считывание данных» это такие большие выборки это вполне ожидаемое поведение платформы. Подробно на этой особенности я не буду останавливаться, а если Вам интересно обратите внимание на статью – http://www.develplatform.com/2013/01/blog-post.html.

Теперь обратим внимание на еще одну особенность. Сразу за подготовкой следующей инструкции (http://msdn.microsoft.com/ru-ru/library/ff848808.aspx):

Мы видим более 300 запросов следующего (одинакового) формата:

Результат выполнения всех этих (связанных) запросов используется следующим образом:

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

Теперь давайте посмотрим, как изменится скорость обновления динамического списка, если в его настройках мы установим в качестве основной таблицы «Документ.киЗаписьРеестраРабот» и включим «динамическое считывание данных»):

Скорость выполнения сократилась (с 21,66 секунд) до 17 секунд:

  • 16,5 секунды на выполнение запросов;
  • плюс ~пол секунды на обновление информации в интерфейсе (трудозатраты должны быть незначительными, т.к. объем передаваемых данных составляет всего несколько десятков килобайт).

Ощутимый прирост, особенное если учесть объем трудозатрат разработчика (установить значение в одном поле и включить признак) на оптимизацию.

Помимо скорости выполнения операции, сократилось и число исполненных СУБД запросов. Теперь их уже не > 300 запросов, а всего 14, что существенно облегчает анализ полученной трассировки.

Посмотрим на текст самого длительного запроса выборки:

Это один из запросов получающий информацию о данных документов «киЗаписьРеестраРабот» для их вывода в динамическом списке. Теперь выборка ограничена 25 документами (ранее ограничение составляло 1000 документов), что более целесообразно (на мой взгляд) при использовании динамического списка.

Изменился и запрос, получающий представления документов (дату и номер) «киЗаписиРеестраЗатрат»:

Теперь это 1, а не ~300 запросов. Может быть, с точки зрения производительности прирост не так ощутим, а вот анализировать трассировку из 14 запросов проще, чем из 375.

Так как рассмотренный инструмент используется большим количеством пользователей – количество исполняемых запросов, формирующих динамический список по данным документа «киЗаписиРеестраЗатрат» существенно выше количества модификаций этих документов. Для более оптимального использования ресурсов и повышения производительности этой операции, целесообразно модернизировать архитектуру хранения данных (создать дополнительный индекс в регистре сведений, консолидирующий информацию из документа «приЗаписиРеестраЗатрат» необходимую для вывода в динамическом списке).

При использовании оптимальной архитектуры хранения данных (и простого запроса, извлекающего данные из одной таблицы, без обращений через точку к реквизитам и соединений с другими таблицами) скорость обновления динамического списка сократилась с 17 до 1,7 секунды, при этом трудозатраты на выполнение запросов (на стороне СУБД) составили ~1,3 секунды:

К слову, скорость обновления списка при использовании оптимальной архитектуры, но без указания «Основной таблицы» и с отключенным «Динамическим считыванием данных» составила:

Аж 4,3 секунды против 1,7.

А в трассировке (судя по количеству запросов, исполненных СУБД для выполнения операции) опять изменилась методика получения представлений для полей ссылочного типа.

Выводы.

Внимательно «следите» за настройками элементов формы вида «динамический список», потому как «одна не к месту поставленная галочка» может снизить производительность (что я и попытался продемонстрировать на примерах), и не используйте сложных запросов в динамических списках (тогда и потребность в использовании «РАЗЛИЧНЫЕ» отпадет). Идеально если для выборки данных будет использоваться одна таблица, индексированная с учетом полей, по которым пользователи «любят» устанавливать сортировку или отборы. При установке индексов, отдельное внимание необходимо уделять индексам с доп. упорядочиванием, которые при правильном использовании могут внести дополнительный вклад в повышение скорости работы динамических списков.

Условия проведения тестов:

  • Динамический список строился по таблице, максимальный размер строк в которой составлял: 239 283
  • Перед сбором каждого замера (скорости обновления динамического списка) на стороне СУБД производилась очистка буферного и процедурного кэшей, что не позволяет оценить влияние встроенных в СУБД инструментов оптимизации производительности на скорость обновления динамических списков. При наличии достаточного количества свободных ресурсов, встроенные механизмы СУБД могут внести дополнительный вклад в производительность работы информационной системы.

Be First to Comment

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *