Оптимизация экранных форм в 1С 7.7   

   
          Ограничение обновления экранных форм.         

          У каждого пользователя 1С на экране обычно открыто несколько экранных форм. Это могут быть списочные формы справочников, журналов документов. Информация в этих экранных формах периодически обновляется. На уровне операций обращения к базе данных проверка обновления экранных форм выглядят примерно следующим образом.

          Каждые "N" секунд выполняется запрос к базе данных «Select NETCHGCN from _1SUSERS(NOLOCK)». Этот запрос возвращает количество изменений в базе с момента старта работы пользователей в ней. Изменением в базе считается любое изменение справочников или документов. Частота опроса базы данных на предмет наличия в ней изменений задается отдельно для каждого пользователя в настройке параметров системы:


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


          Как можно видеть такие параметры как Duration, Cpu, Reads в указанном примере составляют значительные величины, в частности Duration обозначает длительность выполнения запроса и на примере каждый из трех выделенных запросов длится не менее секунды. Количество логических чтений составляет более 200000 операций. Если представить, что каждый пользователь имеет открытыми по 1-2 окна, количество пользователей в базе равно сотне, период опроса 10 секунд, то при интенсивной работе в базе каждые 10 секунд будет генерироваться приблизительно 100-200 операций обновления, которые занимают соответственно от 100 до 300 секунд времени и выполняют примерно 20 000 000 операций логического чтения. При этом часть значительная часть пользователей, работающих в базе может не иметь необходимости в таком частом обновлении экранных форм.
          Проблемы производительности, связанные с работой большого количества экранных форм.
          Так как обновление форм генерирует значительную нагрузку на базу данных, вполне может возникать ситуация, когда нагрузка достигает такой величины, что начинается глобальное «торможение» всех процессов. Это также сказывается на скорости проведения документов, что, в свою очередь, сказывается на количестве блокировок. В результате чрезмерной нагрузки могут вырастать значительные деревья блокировок, выстраиваться очереди по 5-6 процессов и более. Далее процесс нарастает как снежный ком и может потребовать для нормальной работы системы завершения целого ряда процессов на сервере.
          Вот один из примеров такой ситуации на реальной базе:



          На данном рисунке в программе мониторинга производительности "PerfExpert" видно, что было выполнено несколько тяжелых курсоров, связанных с экранными формами. При этом, по данным счетчиков производительности резко снизилось значение счетчика «Page Life Expectancy», показывающего интенсивность использования памяти. В результате повышенной нагрузки увеличилось количество блокировок, целый ряд процессов стал в очередь. На правой части рисунка видно, что выстроилось дерево блокировок трех уровней.

          Вариантов решения данной проблемы и повышения скорости работы 1С два, и они могут использоваться параллельно друг другу. Первый вариант – значительно увеличить период опроса изменений базы данных со стандартных 10 секунд до 30 и более секунд. Тогда обновления будут происходить в 3 раза реже, соответственно, непроизводительная нагрузка на базу данных снизится.
          Второй вариант – отключить обновление. В технологии «Гибкие Блокировки»® реализована возможность полностью отключить обновление экранных форм для каждого пользователя в зависимости от действий других пользователей. Т.е. разрешается следующий режим работы – другие пользователи могут создавать документы, справочники, при этом у данного пользователя система считает, что изменений в базе не было, и не производит обновления экранных форм. При этом если сам пользователь делает изменения, тогда все экранные формы стандартным образом обновляются.
          Данная возможность существует в связи с технологией данимических курсоров. Для данных курсоров информация по текущей строке всегда заново перечитывается из базы, также не определен конец курсора, всегда можно нажать переход в конец или в начало и данные по курсору обновятся. Т.е. пользователь, если хочет проверить, не изменился ли статус документа – может перейти на него – поставить курсор, и в этот момент информация по данному документу будет перечитана и отображена в актуальном виде.Также пользователь может пролистать журнал вниз или нажать кнопку перехода в конец. Курсор последовательно перечитает данные, начиная с текущей позиции и отобразит все новые документы, которые до этого не отображались у пользователя. На рисунке 4 можно увидеть, как реализовано отключение режима обновления в технологии «Гибкие Блокировки».



          Для достижения эффекта достаточно отключить опцию «Разрешить опрос изменения базы данных». По-умолчанию при первом запуске данная опция уже отключена.

          Оптимизация скроллинга экранных форм.

          Данная операция – одна из самых тяжелых операций, выполняемых на экранной форме. Каждое движение колесика мыши преображается в набор команд, подобных тем, что выполняются при обновлении экранных форм. Кроме того, добавляются команды поиска текущего положения курсора в полном списке документов и вычисление нужной позиции, с последующим переходом туда. При этом позиция курсора не меняется, до тех пор, пока не доходит до верха или низа экрана, сдвигается весь экран вниз или вверх.
         Проблемы производительности. Те же, что и для обновления экранных форм, но есть следующие отличия. Нагрузка генерируется тем пользователем, который осуществляет скроллинг, но в связи с количеством событий (скроллинг возникает сразу много раз подряд у одного пользователя) нагрузка на базу также очень большая. Отрицательный эффект на производительность системы аналогичен эффекту, возникающему при обновлении экранных форм.
          В технологии «Гибкие Блокировки» реализовано следующее решение данной проблемы. Существует настройка, позволяющая включить альтернативный вариант скроллинга, при котором курсор двигается по списку точно так же, как он бы двигался при командах с клавиатуры кнопками «вверх» и «вниз». При этом происходит снижение нагрузки на базу и повышение скорости работы 1С. Происходит лишь простое движение по открытому курсору вверх или вниз на определенное количество позиций.
          Количество строк, на которе может осуществляться движение в списке – также указывается в настройках.
          Вот форма настройки:


          Оптимизация быстрого поиска по подстроке для экранных форм.

          Данная проблема актуальная в первую очередь для справочников, так как наиболее часто поиск по подстроке происходит именно в списочных формах справочников. Часто по наименованию ищут сотрудника, контрагента, товар.
          Реализован механизм быстрого поиска следующим образом. Обработка происходит для каждой следующей введенной буквы. Введенная буква добавляется к уже введенному тексту, затем происходит поиск примерно такого вида: «set rowcount 1 select * from SC12(NOLOCK INDEX=DESCR) where DESCR>='К' and substring(DESCR,1,1)='К' order by DESCR,ROW_ID set rowcount 0», затем происходит переход по курсору справочника в начало, а затем на нужную позицию.
          Такие операции повторяются для каждой введенной буквы. Если при этом справочник достигает размеров более 10000 элементов, имеет большое количество реквизитов, то поиск получается достаточно медленным. Кроме того, на форме справочника могут присутствовать различные формулы, которые будут срабатывать каждый раз при перерисовке формы (получается каждый раз после каждой введенной буквы). Это приводит к проблемам с производительностью.
          В технологии «Гибкие Блокировки» реализован механизм поиска, заключающийся в том, что поиск начинается не после каждой буквы, а после завершения ввода всего набора символов пользователем. Пользователь вводит начальные символы, при этом поиск после каждой буквы не происходит. Как только он останавливается, и идет пауза больше определенного времени (длительность этой паузы задается в настройках), то происходит поиск уже введенной части целиком.   Это позволяет снизить количество операций поиска в несколько раз, обычно в 5-10 раз. Соответственно во столько же раз снижается нагрузка на базу, генерируемая операциями поиска и происходит повышение скорости работы 1С в целом.
          Настройка таймаута для поиска происходит на закладке компоненты:


          Ограничение интервала журналов документов.

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

Статья: Оптимизация экранных форм в 1С 7.7

Перейти на главную страницу компании "Софтпоинт"