Замер производительности в отладке 1С 8.3

Замер производительности — встроенный функционал платформы 1С 8 для оценки производительности программного кода в режиме отладки 1С.

С помощью этого механизма возможно оценить производительность в разрезе строк программного кода. Рассмотрим использование этого механизма подробнее на конкретном примере.

Пример использования замера производительности 1С

Запускаем 1С 8.3 в режиме отладки, устанавливаем точку останова, запускаем режим замера из меню (Отладка — Замер производительности).

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

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

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

Видео, как запустить замер в отладке 1С:

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

APDEX и замеры производительности 1С

Введение

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

У нас в Кнопке пользователями продукта 1C Fresh в первую очередь являются наши бухгалтеры. Чем выше стабильность и скорость работы 1С, тем выше скорость работы бухгалтера. А это значит, что клиенты, которые обслуживаются в Кнопке будут быстрее получать расчеты по налогам, авансу, зарплате и т.д.

Существует много различных вариантов оценки производительности (или качества) IT — систем и софта. Для оценки производительности нашего 1С Fresh мы используем многим известную методику APDEX.

Apdex. Справка

Apdex (Application Performance Index) — индекс производительности приложений. Открытый международный стандарт, разработанный с целью формирования объективной оценки показателей производительности корпоративных информационных систем.

Apdex служит для измерения пользовательской удовлетворенности работой системы. Этот опыт может быть представлен по шкале от отлично до неудовлетворительно.

Методика состоит из следующих этапов:

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

По завершению всех перечисленных этапов становится возможным интерпретировать полученный результат в терминах качественной оценки. Про Apdex есть информация на сайте 1С, откуда мы собственно и черпали знания.

Реализация. Теория

Первым этапом при замере производительности по методике Apdex, является выделение списка ключевых операций. Проведя некоторую аналитику совместно с нашими бухгалтерами, мы выделили ряд операций, которые чаще остальных используются в работе с 1С.

Второй этап — определение приоритета каждой операции. Чем выше приоритет, тем важнее производительность операции. Правильно расставленные приоритеты позволят в дальнейшем оценить серьезность проблем с производительностью в системе, и правильно определить приоритеты работ по оптимизации.

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

Следующий этап, это сбор информации о времени выполнения каждой операции. 1С позаботились об этом и учли такой функционал в своих продуктах. Замеры мы снимали с конфигурации Бухгалтерия Предприятия 3.0. Для того, чтобы 1с начала замерять время выполнения операций, необходимо установить константу «Выполнять замеры производительности». Проделать это нужно для каждой ИБ, работающей в модели сервиса.
После этого все замеры времени выполнения пользовательских операций будут записываться в регистр сведений «Замеры времени», откуда эту информацию можно получать различными способами.

И, наконец, пятый этап, получение оценки APDEX на основании собранных результатов.

Формула для вычисления APDEX: APDEX = (NS + NT/2)/N

N — общее количество выполнений данной операции;
NS — количество выполнений с временем отклика от 0 до Т;
NT — количество выполнений с временем отклика от T до 4T.

Результаты расчетов добавим в таблицу:

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

Реализация. Практика

Для мониторинга производительности и доступности сервисов, мы используем Zabbix и надстройку Grafana. Для всех наших сервисов, в том числе 1C Fresh, мониторятся следующие показатели: нагрузка на CPU каждого сервера, количество свободной оперативной памяти, глубина очереди дисковой подсистемы (нагрузка операциями дискового ввода/вывода), количество свободного места на дисках, количество операций INSERT, UPDATE, DELETE в секунду на сервере СУБД.

Для отслеживания оценки Apdex мы не стали придумывать ничего нового и добавили отображение оценки в Zabbix. Для того, чтобы Zabbix получал данные по времени выполнения операций из 1с, их нужно сначала куда-то выгрузить. Для этого мы используем промежуточную базу PostgreSQL. Выгружать данные из 1С в базу можно несколькими способами. Мы реализовали этот механизм через регламентные задания.

Каждое регламентное задание можно запускать по расписанию:

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

Для выгрузки мы будем использовать следующие значения регистра:

1. Наименование базы прикладной конфигурации. Поскольку в технологии 1C Fresh предполагается использование большого количества баз и прикладных решений, нам необходимо различать замеры для каждой из них
2. Наименование операции.
3. Время начала операции
4. Время выполнения операции
5. Область данных, в которой выполнялась операция
6. Пользователь, выполнивший операцию

Фоновое задание представляет собой процедуру:

Выгружая таким образом данные из 1С, нам теперь не составит труда обрабатывать это в Zabbix’e. На примере операции “Общее время запуска приложения” в ИБ ea_01 сформируем sql-запрос к базе:

На первом шаге создадим конфигурационный файл для агента, который будет выполняться на сервере СУБД где хранятся данные замеров.

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

На втором шаге мы создадим шаблон в Zabbix, где будем описывать необходимые нам макросы:

Затем привязываем этот шаблон к нужному узлу сети и переопределяем индивидуальные параметры для макросов.

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

Теперь, почти в режиме реального времени, мы видим оценку Apdex по нашим базам 1cFresh. Но мы пошли дальше.

Настройка реакции на падение производительности

Кроме автоматического мониторинга показателей мы настроили также автоматическую реакцию на падение производительности по какому-либо параметру. Zabbix предоставляет большой простор для реализации различных реакций через скриптовые инструменты.

Мы будем реагировать на падение производительности включением технологического журнала «1С: Предприятие».

Сценарий достаточно прост:

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

После разбора проблемы, либо восстановления производительности, проводятся обратные действия.

Производительность выходит на нормальный уровень → срабатывает триггер → удаляется блок настроек технического журнала.

Создадим триггер, в котором прописываем условия срабатывания. В нашем случае это падение оценки Apdex ниже 0.6

Затем создаем действие, на срабатывание триггера

В этом действии задаем команду

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

Благодаря мониторингу и оценке производительности, мы смогли выйти на показатель 99% доступности нашей инсталляции 1C Fresh. Наши показатели оценки Apdex пока еще не достигли 1.0, но мы уже над этим работаем 🙂

Источник

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

Получение начальной оценки интегральной производительности системы

Перед началом работ по оптимизации системы необходимо всегда получать начальную оценку производительности при помощи “Оценки интегральной производительности системы по методике APDEX”.

Если по данным Apdex видим, что существуют такие ключевые операции, оценка производительности которых “Неприемлемо”, “Очень плохо” или “Плохо”, то необходимо выполнять работы по оптимизации таких операций в порядке их приоритетов.

Анализ сырых данных Apdex

Первым шагом при выполнении работ по оптимизации выбранной ключевой операции будет анализ сырых данных Apdex. Для корректного анализа число замеров должно быть значительным, например, больше 100.

По сырым данным Apdex нужно понять:

Если в полученном распределении имеется несколько пиков, то нужно понять:

Получим распределение времени выполнения операции.

Для этого необходимо воспользоваться обработкой “Оценка производительности”, которая входит в состав одноименной подсистемы БСП и в ЦКК (Центр контроля качества, входит в состав Корпоративного инструментального пакета).

С помощью встроенной обработки “Оценка производительности” (её можно найти в настройках контрольной процедуры “Контроль производительности”) существует возможность получать распределение времени выполнения одной или нескольких ключевых операций за любой период времени.

Как обработка получает распределение времени? Выбираются необходимые данные замеров времени по ключевой операции за интересующий нас период времени из регистра сведений ЗамерыВремени.

Регистр сведений ЗамерыВремени является частью подсистемы ОценкаПроизводительности, включенной в состав Библиотеки Стандартных Подсистем. Далее рассчитывается распределение частоты времени выполнения ключевой операции по периодам времени. Длительность периода выполнения выбирается экспертом самостоятельно в зависимости от целевого времени T и от сырых данных Apdex и настраивается на форме обработке. По умолчанию длительность периода 0,5 секунды. Очень желательно, чтобы среднее и медианное время выполнения операции попали в выбранный диапазон.

Рассмотрим, для примера ключевую операцию “Проведение документа “Заказ покупателя””.

Выберем длительность периода 1 секунда, и разобьём все значения замеров времени по периодам, например от 0 до 6 секунд. Каждый следующий замер времени из сырых данных Apdex будет отнесен к своему периоду. Например, замер операции, которая выполнилась за 1,51 секунды, будет отнесен к периоду от 1 до 2 (т.е. к периоду (1,2], или просто 2). Если операция выполнилась за 1 секунду, то её замер будет отнесен к периоду от 0 до 1 (т.е. к периоду (0,1], или просто 1). Когда определен период, к которому относится выбранный замер, счетчик числа замеров этого периода увеличивается на 1.

Также в обработке “Оценка производительности” существует возможность выбирать пользователей, по которых необходимо получить оценку производительности за выбранный период времени

В результате по данным замеров времени получаем следующее распределение времени выполнения операции.

Видим распределение времени выполнения операции с одним пиком.

Если время выполнения выглядит так:

то это говорит о неверно встроенных счетчиках замеров времени. Мы наблюдаем два пика, при этом первый из них меньше 0,5 секунды.

Такое распределение характерно для замеров проведения документов, которые начинаются, но не завершаются корректно из-за какой-либо ошибки выполнения операции.

Если время выполнения выглядит так:

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

В результате анализа распределения времени выполнения операции, видим за какое время чаще всего выполняется операция.

Следующим шагом нужно будет попытаться воспроизвести время выполнения операции, которое:

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

Воспроизведение медленного выполнения операции

Необходимо правильно воспроизводить медленное выполнение операции.

Вы можете получить два результата:

При воспроизведении медленного выполнения операции необходимо всегда замерять время выполнения операции по секундомеру.

Очень важно понимать, какую именно операцию нужно воспроизвести. Мы не просто так искали пик распределения времени.

Мы его искали для того, чтобы потом найти операцию, которая попадает в этот пик, и выполнять именно её.

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

При воспроизведении необходимо постараться получить условия, в которых операция выполняться быстро, медленно.

Например, пользователь в рабочей системе наиболее часто выполняет операцию за время, близкое к 4 секундам. А целевое время операции T = 1,5 секунды.

Если выполнять операцию в рабочее время, то мы “попадаем в пик”, если выполнять операцию в нерабочее время, то мы воспроизводим 1,8 секунды.

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

Далее, по очереди смотрим:

Если операция чаще всего выполняется в веб клиенте, нужно обязательно проверить скорость её выполнения в тонком клиенте и в различных браузерах.

Если воспроизводится медленное выполнение операции

Основной задачей будет: понять, НА ЧТО уходит большая часть времени выполнения операции.

В первую очередь предлагается получить:

Получать все выше перечисленные данные нужно от 1, 2 и 3 выполнения ключевой операции. Первое выполнение должно быть несколько дольше второго и третьего выполнения операции.

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

Более детально этот вопрос отражен в статье Отладка прикладных решений

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

Рассмотрим, как можно получить суммарное время выполнения всех запросов на примере MS SQL Server.

Для этого требуется собрать трассировку с помощью MS SQL Profiler по следующим классам событий от одного выполнения операции:

У перечисленных классов событий обязательно должны собираться данные по полю Duration, т.к. данные по этому полю необходимо будет проанализировать в первую очередь.

DatabaseID можно получить, выполнив запрос:

О том, как фильтровать события в трассировке, есть статья от Microsoft.

Трассировку от одного выполнения операции нужно сохранить в выбранную вами (любую, но НЕ рабочую базу) базу данных, как таблицу, назовем её trace_table_1.

Войдите в выбранную вами базу с помощью MS Server Management Studio и выполните запрос:

Достоинство такого подхода:

Рассмотрим, как можно получить суммарное время выполнения всех запросов с помощью технологического журнала.

Для этого сначала подготовим файл logcgf.xml.

Событие DBMSSQL позволит собрать все SQL запросы технологической платформы 1С к СУБД MS SQL Server с фильтром по одной базе db.

позволит сразу же получить планы запросов, что позволит проанализировать причину неоптимального выполнения запросов (если, конечно, проблема будет именно в них).

Внимание! При работе с СУБД Oracle НЕ нужно собирать планы при сборе технологического журнала, т.к. это приведет к значительному замедлению работы системы в целом.

Такой файл необходимо расположить на сервере в директории “\bin\conf”.

В ОС Windows для технологической платформы версии 8.2.18.101 путь к расположению этого файла будет выглядеть так:

Необходимо до копирования файла logcfg.xml в указанную директорию подготовиться выполнить ключевую операцию.

Это нужно сделать для того, чтобы в собранный технологический журнал в директорию “C:\LOGS\KO1” не попали никакие другие запросы, которые не относятся к ключевой операции.

После того, как вы скопировали файл logcfg.xml с нужными настройками в “\bin\conf” нужно подождать 1 минуту и НЕ выполнять никаких действий.

Дело в том, что платформа читает файл logcfg.xml один раз в минуту, поэтому необходимо подождать и убедиться, что журнал начал собираться с нужными нам настройками.

Выполните операцию один раз и получите от ОДНОГО выполнения ключевой операции:

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

В этом событии DBMSSQL мы видим, что пользователь от имени “Анна” выполнил запрос в базе “db”, который завершился в 50 минут 21,1251 секунду и длился 0,012 секунды.

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

Нужно ответить на вопросы:

Время, которое работал код платформы на языке 1С, который относится к данной ключевой операции, можно увидеть, нажав Ctlr + A в замере конфигуратором.

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

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

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

Бывают ситуации, когда время равномерно “размазано” по нескольким отрезкам, то есть, явного лидера не видно. Такое возможно как в самом начале, так и на поздних этапах оптимизации операции, когда все явные проблемы были уже устранены.

В этом случае стоит рассмотреть архитектурные способы оптимизации. Например:

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

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

Если не воспроизводится медленное выполнение операции

Если в однопользовательском режиме не воспроизводится медленное выполнение операции, нужно:

Одной из наиболее частых причин, из-за которой не воспроизводится медленное выполнение операции, является наличие очереди к ресурсам. Симптомом этой проблемы будет тот факт, что операция выполняется быстро именно в однопользовательском режиме, а в рабочее время скорость выполнения операции значительно ниже.

В ЦКК в подсистеме Мониторинга также возможно добавить один или несколько показателей производительности Apdex

Возможно вывести на это же график (или на отдельный график в режиме “Анализ показателей”) время выполнения выбранной ключевой операции (в секундах).

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

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

Причиной такой корреляции могут быть очереди на оборудовании. Для того чтобы их исключить, необходимо проанализировать загруженность оборудования на рабочих серверах “1С:Предприятия” и сервере СУБД.

Часто наиболее узким местом становится именно дисковая подсистема на серверах СУБД. Тут важно не торопиться и не принимать сразу решение о покупке дорогостоящего хранилища. Ситуацию можно значительно улучшить за меньшие деньги. Для этого понадобится понять, а какие именно запросы создают наибольшую нагрузку на дисковую подсистему сервера СУБД. В результате выявления наиболее узких мест, необходимо будет решать, как их устранить.

Также среди причин могут быть избыточные ожидания на блокировках. Для расследования этой проблемы необходимо подключить ЦУП и собрать аналитику по ожиданиям на блокировках за 15 минут работы системы.

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

Как найти запросы, создающие высокую нагрузку на дисковую подсистему сервера СУБД

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

Ниже приведена методика на примере MS SQL Server. Если у вас используется другая СУБД, то смысл методики не меняется, изменится только инструмент.

1. Настройте MS SQL Profiler по классам событий

Для выбранных классов событий оставьте поля

Установите фильтры по DatabaseID (на исследуемую базу), Reads > N, где N может меняться от 1000000 до 10000. Начните с 1000000. В следующих трассировках можете уменьшить это число. Ваша трассировка должна быть достаточного объема, чтобы делать по ней выводы.

2. Соберите трассировку в пике нагрузки на систему в течение нескольких минут.

3. Сохраните трассировку в отдельную базу данных как таблицу.

4. Сгруппируйте все запросы по TextData, посчитав сумму Reads. Посчитайте суммарное число логических чтений, которое создает какой-либо запрос. В результате вы найдете один или несколько запросов, которые создают наибольшую нагрузку на чтение.

5. Теперь остается найти самый тяжелый (или несколько тяжелых) по числу чтений запрос в коде конфигурации. Например, можно настроить технологический журнал с фильтрами только на один запрос. Может выглядеть так:

Смысл в том, чтобы указать такие фильтры:

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

6. Проанализируйте план запроса, частоту выполнения запроса.

При выполнении этих шагов может оказаться, что запросов таких немного, и они имеют неоптимальные планы. Может оказаться, что есть методические ошибки, например, запросы в цикле. Вы их увидите, сделав группировку по тексту запроса. В этом случае также придется исправлять в коде конфигурации. Группируя тексты запросов, вы можете понять, что на самом деле, большая часть тяжелых запросов строится “вокруг” одного или нескольких таблиц. В этом случае стоит подумать о построении промежуточных технологических таблиц, которые будут хранить посчитанные значения. Используйте механизмы платформы (например, агрегаты) там, где это возможно.

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

Источник