Интернет-магазин Доставка

Мы выбрали для Вас офис в Москве.

Вы можете изменить его на офис в другом городе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используется трехзвенная клиент-серверная архитектура с доступом тонкого клиента через веб-сервер. Сервер СУБД и Сервер 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С» процесса открытия формы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример иного случая возникновения событий 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С».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Проверяем в опциях, что установлен флаг «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";

      Запустить Fiddler, зайти в правила (Rules) и в событии OnBeforeRequest добавить правило переадресации вида

      Запустить Fiddler, зайти в правила (Rules) и в событии OnBeforeRequest добавить правило переадресации вида

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

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

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

Откроем форму бюджета, дождемся окончания открытия и посмотрим, все пакеты от запомненного до самого последнего

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

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

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

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

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

Примечание:

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

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

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

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

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

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

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

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

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

Справа видим данные формы

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

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

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

  • 10668,
  • и 903,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

Авторы статьи

Романов Даниил
Романов Даниил
Черанев Андрей
Черанев Андрей
Заинтересованы в сотрудничестве?
Нужна консультация?
Свяжитесь с нами!
Для отображения персонализированного контента и рекламных сообщений, а также хранения личных настроек на локальном компьютере веб‑сайты «1С‑Рарус» используют технологию cookie и аналогичные. Продолжив использование наших веб‑сайтов, Вы даете согласие на обработку персональных данных, выражаете согласие с Политикой конфиденциальности rarus.ru и применением этих технологий.
Продолжив использование веб‑сайтов «1С‑Рарус», Вы даете согласие на обработку персональных данных, выражаете согласие с Политикой конфиденциальности.
Facebook Vkontakte Youtube Instagram