От экспертов «1С-Рарус»: Ускоряем в 3 раза открытие сложной формы в 1С 8.3

Долгое ожидание при открытии формы бюджета в «1С»

В финансовых решениях консолидационного класса или класса ERP предлагается функциональность, связанная с составлением оперативных или мастер-бюджетов, например, работа с бюджетом доходов и расходов.

Экземпляр бюджета — это хрестоматийный пример сложной формы, где есть:

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

Как видно, логика работы достаточно нагруженная и, как следствие, данных на форме много.

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

После разработки и включения в рабочую базу оказалось, что открытие формы бюджета в терминах структур разделов и статей компании занимает 1,5 минуты и более. Это неприемлемо, тем более что основные пользователи системы — руководители подразделений, и без того сталкивающиеся с нехваткой времени.

Мы поставили перед собой задачу сократить открытие такой формы до времени <= 30 секунд.

Программная и аппаратная инфраструктура

Конфигурация «1С»:

• Нетиповая конфигурация собственной разработки.

Замечание: подобные проблемы могут также быть актуальны для иных систем класса ERP, например:

• 1С:ERP,
• 1С-Рарус: Финансовый менеджмент.

Используется трехзвенная клиент-серверная архитектура с доступом тонкого клиента через веб-сервер. Сервер СУБД и Сервер 1С:Предприятия совмещены на одной машине.

Сервер СУБД

Аппаратная часть:

• Процессор: Intel Xeon CPU E5-2637 v2, 2 процессора 3,5 Ghz.
• Память: 96 GB (разрешено потреблять СУБД не более 73728 MB).
• Жесткий диск SSD.

Программная часть:

• MSSQLServer 2014 (12.0.4237.0).
• MS Windows NT 6.1 (7601).

Сервер «1С:Предприятие»

Аппаратная часть:

• Тот же сервер, что и сервер СУБД.
• Память: доступна вся свободная память, то есть, не менее 24576 MB.

Программная часть:

• 1С 8.3.14.1694.

Веб-сервер

Аппаратная часть:

• Процессор: Intel core 2 DUO E7500 2,93 GHz.
• Память: 4 GB.

Программная часть:

• MS Internet Information Services 8.5.96.
• MS Windows Server 2012 R2.

Тонкий клиент

Аппаратная часть:

• Процессор: Intel Core i5.
• Память: 16 GB.
• Диск SSD.

Программная часть:

• 1С 8.3.14.1694 — тонкий клиент.
• MS Windows 10.

Ищем причину медленного открытия формы и устраняем ее в «1С»

1. Для начала расследования снимаем замер производительности в «1С» процесса открытия формы

В замере видно, что лидер по абсолютному времени выполнения — метод «ОткрытьФорму».

Из 104 секунд открытия 64 приходятся на этот метод.

При этом сделать вывод о причинах медленного открытия из этого замера невозможно.

2. Соберем технологический журнал для анализа медленного открытия

Какие события собираем

Собираем события CALL и SCALL.

Выдержка из документации по платформе:

• SCALL — исходящий удаленный вызов (исходящий вызов на стороне источника вызова).
• CALL — входящий удаленный вызов (удаленный вызов на стороне приемника вызова).

Эти события возникают при клиент-серверном взаимодействии.

Бытует мнение, что SCALL всегда возникает при обращении с клиента на сервер, а CALL — при приходе этого обращения на сервер.

Нередко это так и есть, например, когда клиент обращается к серверу.

Однако это не всегда так. Например, могут быть обращения внутри сервера между менеджером кластера и рабочим процессом, между сервером и клиентом и так далее.

Пример иного случая возникновения событий CALL и SCALL.

Цели сбора

Преследуем 2 цели:

• посмотреть длинные по времени вызовы;
• найти «лаги» в технологическом журнале.

С длинными вызовами вопросов не возникает: есть оператор программы, который длится слишком долго, и это можно в явном виде обнаружить в ТЖ. По сути, хотим увидеть то же, что в замере производительности.

Что такое «лаг технологического журнала»? Под ним понимается ситуация, когда в явном виде событий с большим временем исполнения в журнале нет, но косвенно об этом догадываемся за счет присутствия большой паузы между двумя соседними событиями в журнале по одной сессии.

Метод сбора

Метод сбора технологического журнала (далее — ТЖ) — обычный:

• в папке C:\Program Files\1cv8\conf создаем файл logcfg.xml (структура файла ниже);
• ждем, пока в папке с логами, указанной в logcfg, появятся подпапки с именами процессов сервера;
• выполняем открытие формы;
• убираем файл logcfg.xml из папки;
• ждем не более 5 минут, пока система завершит запись файлов журнала;
• забираем файлы технологического журнала из подпапки rphost_<номер процесса>.

Структура файла:

В нем настроено:

• папка для сбора логов C:\logs;
• отбор по событиям CALL и SCALL;
• отбор по имени базы rarus_fb.

Анализируем данные собранного лога технологического журнала. Нехитрым скриптом посмотрим наиболее долгие вызовы.

Примечание по скрипту

По сути, скрипт отбирает из ТЖ события, с длительностью от 2 знаков (с 10 секунд и более). Т. к. время в ТЖ 8.3 — в микросекундах, то нам нужен отбор по времени > 8 разрядов; чтобы не писать много букв в регулярном выражении, используем синтаксис расширенных регулярных выражений: {8,}, который включается ключом -E.

Видим, что существует долгое событие CALL длительностью 85 секунд, на котором происходит большое потребление памяти 554 Мб, а в пике 701 Мб и оно возникает на методе ПолучитьФорму.

Соберем лаги ТЖ.

Сделаем это более сложным скриптом, суть которого в том, чтобы сравнить по времени 2 соседних события ТЖ и найти среди них наибольшие паузы.

egrep "^[0-9][0-9]\:[0-9][0-9]\.[0-9]+\-[0-9].*,t:clientID=76840," open_budg19061011.log  | awk -F\- '{print $1;}' | sed -e 's/\./:/g' | awk -F\: '{ min = $1; sec=$2; mmsec=$3; event=$0; getline; print ($1*60*1000000 + $2*1000000 + $3) - (min*60*1000000 + sec*1000000 + mmsec)" : "event" - "$0;}' | sort -rnb | head > lags2.txt

Примечание:

• в скрипте делаем отбор по t:clientID, равному ID нашего клиента, чтобы учесть только события по текущему пользователю.

В результате получаем:

В первой колонке — время лага в микросекундах, далее — время старта двух соседних событий.

Видно, что первым номером идет лаг, сопоставимый по времени с временем открытия формы.

Делаем предположение, о том, что тяжелая форма долго загружается с сервера на клиент.

3. Посмотрим на форму в конфигураторе

Что же такое разработчик заложил на форме? Может быть данные формы перегружены избыточной информацией?

Важный элемент расследования — просто посмотреть на творение рук разработчика глазами в конфигураторе «1С».

Видим несколько таблиц значений на форме. Отладчиком посмотрим для реального бюджета, какое количество строк в них.

А строк совсем немало. И всё это при открытии перегружается с сервера на клиент.

Убедимся в этом тезисе.

4. Используем Fiddler в режиме ReverseProxy

Чтобы окончательно убедиться в том, что медленная работа обусловлена «большими» данными формы и понять, что именно это за данные, перехватим их.

Для перехвата встроим между веб-сервером и тонким клиентом «1С» программу Fiddler в режиме Reverse proxy. Эта программа по сути является отладчиком при передаче данных по протоколу http.

Режим Reverse proxy позволяет «вставить Fiddler в разрыв» между веб-сервером и клиентом и проанализировать пакеты обмена.

Настройка Fiddler в режиме ReverseProxy

Настройку будем производить на копии рабочей базы, которая развернута в той же инфраструктуре.

Настройка режима состоит на верхнем уровне из двух этапов:

• настроить на веб-сервере переадресацию url-rewrite на сервер с Fiddler’ом;
• настроить сам Fiddler.

Для настройки веб-сервера вводим правило url-rewrite на сервер finsrv, порт 8888, на котором будет слушать Fiddler.

Устанавливаем на отдельный сервер наш Fiddler и настраиваем в режиме Reverse proxy, как описано здесь.

1. Проверяем в опциях, что установлен флаг «Allow remote computers to connect».

   

2. Закрыть Fiddler, открыть Regedit и в раздел

   HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2

   добавить ключ ReverseProxyForPort типа DWORD, значение параметра должно быть равно номеру локального порта, на который Fiddler делает переадресацию полученных пакетов.
3. Запустить Fiddler, зайти в правила (Rules) и в событии OnBeforeRequest  добавить правило переадресации вида.
   • if (oSession.host.toLowerCase() == "webserver:8888") oSession.host = "webserver:80";

     

     

Отслеживаем взаимодействие между веб-сервером и клиентом «1С»

Теперь мы можем отслеживать все http-пакеты между веб-сервером и клиентом «1С».

Зайдем в копию базы и дойдем до открытия формы экземпляра бюджета, но открывать не будем. Перейдем в Fiddler, посмотрим, пакет с каким номером был получен последним, и запомним его номер. Теперь откроем форму бюджета, дождемся окончания открытия и посмотрим все пакеты от запомненного до самого последнего.

Видим входящий запрос с большим объемом данных.

Предполагаем, что это и есть данные формы. Смотрим подробности данных в правом окне:

Обращаем внимание, что прочитать можно только заголовки, а данные, похоже, сжаты, о чем также свидетельствует надпись 1C‑SDCversion и далее — MZ, что соответствует началу сжатой части.

Примечание:

• По 1C-SDCversion — ищем на партнерском форуме «1С» и встречаем упоминание о том, что это метод сжатия deflate.

Вспоминаем, что по умолчанию клиент «1С» запрашивает работу со сжатием данных между клиентом и сервером.

С помощью запуска тонкого клиента со специальным параметром отключаем этот режим.

Делаем повторное открытие формы и видим в Fiddler’е уже вполне читаемую картину.

Обращаем внимание, что без сжатия данные формы весят более 1 Мб, что немало.

Наконец справа видим данные формы:

Переходим на представление «TextView», копируем в буфер и сохраняем как xml.

Обращаем внимание на наличие больших блоков в ветке props c внушительным количеством строк, которое сопоставимо с числом строк таблиц значений на форме:

• 10668,
• и 903,

а также со свойством fullChanged="true". Последнее скорее всего означает разрешение на изменение строк объекта на клиенте.

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

С точки зрения функционирования алгоритма они не требуются на клиенте. Принимаем решение избавиться от таблиц значений на клиенте.

5. Разгружаем форму в «1С»

Что тяжелее всего?

• На форме есть таблицы значений с большим числом строк.
• Обработка объект содержит табличные части с большим числом строк.

Отказываемся от использования таблиц значений на форме и табличных частей в пользу такого подхода:

• на сервере создаем таблицы значений;
• при переходе на клиента помещаем их во временное хранилище, а на форме храним только его адрес;
• после возврата на сервер получаем таблицы значений из временного хранилища.

6. Смотрим в Fiddler результат «разгрузки» формы

Видно, что объем данных формы сократился более чем в 5 раз.

7. Делаем повторный замер производительности и смотрим потребление памяти и лаги в ТЖ

Накатываем изменения на рабочую базу, собираем замер производительности «1С».

Видим, что теперь открытие формы экземпляра бюджета составляет 25 секунд, а метод ОткрытьФорму — всего 2,1 секунды.

Собрав технологический журнал, видим следующее:

• Потребление памяти при открытии формы составляет 163 Мб (в пике — 286).
• Временной лаг — всего 8 секунд.

Выводы

• В данной статье была рассмотрена ситуация замедления работы системы при открытии «тяжелой формы».
• Показаны методы анализа причин медленного открытия через замер производительности «1С», анализ технологического журнала и http-отладчик Fiddler.
• Даны приемы анализа технологического журнала для поиска «долгих операций» и «временных лагов».
• Показана настройка отладчика http-запросов Fiddler для анализа отправляемых с сервера на клиент данных.
• Показано, как разгрузка формы от «ненужных на клиенте» данных ускоряет работу системы и снижает потребляемую память.
• Работа пользователей перестала быть дискомфортна за счет сокращения времени открытии формы экземпляра бюджета более чем в 3 раза — с 90 до 27 секунд.