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

Введение

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

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

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

Apdex. Справка

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

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

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

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

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

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

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

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

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

Операция	Приоритет	Т
Проведение поступление товаров и услуг	3	1
Общее время запуска приложения	2	3
Формирование отчёта «карточка счёта»	6	4
Формирование ОСВ	4	3
Формирование ОСВ по счёту	5	3
Проведение реализация товаров и услуг	1	3

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

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

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

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

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

Операция	Приоритет	Т	N	NS	NT	APDEX
Проведение поступление товаров и услуг	3	3	387	320	34	0,67
Общее время запуска приложения	2	5	357	185	164	0,68
Формирование отчёта «карточка счёта»	6	4	99	94	5	0,84
Формирование ОСВ	4	4	224	190	31	0,95
Формирование ОСВ по счёту	5	4	732	559	158	0,88
Проведение реализация товаров и услуг	1	4	387	353	34	0,67

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

• От 0.00 до 0.50 — неприемлемо
• От 0.50 до 0.70 — неудовлетворительно
• От 0.70 до 0.85 — удовлетворительно
• От 0.85 до 0.94 — хорошо
• От 0.94 до 1.00 — отлично

Интерпретировав значения, получим следующую таблицу:

Операция	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, но мы уже над этим работаем 🙂

Источник

Оценка производительности типовым механизмом БСП

Доброго времени суток!

Сижу разбираюсь в типовом замере производительности БСП. Есть ряд вопросов, ответы на которые не могу найти:

1) Как методологически правильно выполнять замер, если процесс начинается на «Клиенте», потом уходит на «Сервер» и там запускаются длительные фоновые операции ?

2) У типового метода «завершить замер» есть параметр — «Автозавершение». Но нигде не могу найти описание — по какому принципу система понимает ,что замер нужно завершить.

Может статьи есть актуальные или просто кто-то «в теме» ?

(1) Так а как система определяет, что состоялся конец процедуры?

Я на тесте делаю так:

(2) + Клиентская процедура, в ней начинаю замер с автозавершением. Далее ухожу в серверную процедуру — что-то там делаю.

Выполняю это в предприятии. Через какое-то время замер действительно появляется в РС, но я понять не могу — как система определяет «финиш» ?

(4) Я не хочу «методом тыка» пытаться понять всю ту «наркоманию», которую выжали из себя разработчики БСП. Это не прокатывает.

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

«Для начала замера времени выполнения ключевой операции необходимо вызвать функцию НачатьЗамерВремени общего модуля ОценкаПроизводительностиКлиентСервер. Если операция начата на клиенте, то она завершится автоматически. Если операция начинается на сервере, то для завершения замера времени необходимо вызывать функцию ЗакончитьЗамерВремени общего модуля ОценкаПроизводительностиКлиентСервер.»
https://its.1c.ru/db/bsp22doc#content:218:1:issogl1_настройка

Этого вполне достаточно, чтобы использовать.

Источник

Методика расследования проблем производительности в сервисе 1cfresh

В статье рассказывается о методике расследования причин проблем производительности в облачных сервисах, построенных на основе технологии 1cfresh.

Облачные сервисы, построенные на основе технологии 1cfresh, обладают рядом особенностей по сравнению с обычными внедрениями. В том числе:

• Абсолютное большинство пользователей работает территориально удаленно от администраторов сервиса, зачастую в другом часовом поясе;
• Удаленный доступ к рабочему месту пользователей существенно затруднен или невозможен;
• Предъявляются повышенные требования к производительности и доступности информационных баз;
• Нельзя воспользоваться отладкой на рабочих серверах;
• На рабочей площадке ограничена возможность использования типовых инструментов расследования проблем, типа ЦУПа, из-за их негативного влияния на производительность сервиса;
• Сервис развернут на большом количестве серверов, в результате сложность поиска проблемы возрастает в разы;
• Накладываются строгие ограничения на доступ к данным информационной базы, в результате данные для воспроизведения очень сложно получить.

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

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

Категории проблем

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

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

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

Методы классификации

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

• Время выполнения операций, рассчитаное по различным методикам, например, Apdex или среднее время наихудших замеров;
• Наличие жалоб от других пользователей;
• Счетчики производительности (загруженности) оборудования;
• Счетчики, встроенные в подсистему ЦентрМониторинга;
• Воспроизводится ли проблема в тестовой базе (или в другой ноде) или в тестовой области в рабочей базе.

Для расследования проблем производительности в сервисе критически важно организовать централизованный сбор данных замеров производительности и агрегацию показателей Apdex. Для этого следует использовать возможности ЦКК по импорту замеров производительности. Необходимость использования ЦКК для этой цели связана, во-первых, с возможностью горизонтального масштабирования сервиса, что приводит к тому, что один и тот же пользователь сервиса может работать параллельно в нескольких информационных базах. Как следствие, данные о замерах также хранятся во множестве информационных баз. Во-вторых, доступ с данным замеров в разделенной информационной базе требует наличия у специалиста, занимающегося вопросами производительности, административного доступа к данным, который в общем случае отсутствует. В третьих, в ЦКК встроены намного более развитые средства для анализа замеров, чем в любые другие конфигурации.

Рассмотрим особенности каждого класса проблем подробно.

Общая медленная работа сервиса у всех пользователей

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

Для выявления факта того, что проблема воспроизводится у большого количества пользователей (массовая проблема), необходимо понять:

• Есть ли аналогичные обращения от других пользователей
  Как правило, массовые проблемы с производительностью сервиса приводят к большому количеству обращений, поэтому перед началом анализа имеет смысл выяснить, единичное ли поступившее обращение или нет.
• Как изменялся Apdex за последнее время
  Для этого необходимо проанализировать динамику Apdex и по системе в целом, и по обратившемуся пользователю.
  Рекомендуется использовать для этой цели отчет «Анализ производительности» ЦКК, сформировав его с отбором по отдельному пользователю, а затем без отбора.
  Например, факт резкого изменения производительности всего сервиса указывает на то, что в системе произошли какие-то изменения:

рис.1 График Apdex за период по сервису в целом

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

рис.2 График Apdex за период по определенному пользователю

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

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

Для выполнения анализа среднего времени выполнения операций можно воспользоваться формой мониторинга ЦКК:

рис.3 График среднего времени выполнения операций за период

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

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

Медленная работа определенной функциональности у всех пользователей, либо у значительной части пользователей

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

Медленная работа определенной функциональности у определенных пользователей

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

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

Типичные причины проблем производительности

Общая медленная работа сервиса у всех пользователей

• Резкая деградация производительности
  • Изменения в настройке оборудования;
  • Изменения в конфигурации информационной базы;
  • Изменения настроек программных продуктов;

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

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

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

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

Диагностировать длительные запросы можно путем анализа технологических журналов по событиям DBMSSQL (или другие в зависимости от используемой СУБД) и SDBL, либо используя ЦУП. При использовании MSSQL также имеет смысл проанализировать, какие виды ожиданий чаще всего возникают на сервере (подробнее тут).

Диагностировать длительные вызовы можно путем анализа технологических журналов по событиям CALL, SCALL, VRSREQUEST, VRSRESPONSE.

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

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

Есть две основных причины проблем такого рода:

• Нетипичное наполнение области
  • Большой объем данных
  • Нестандартные настройки

• Проблемы подключения
  • Медленный компьютер
  • Низкая скорость интернет-канала
  • Нестабильный интернет-канал

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

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

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

Если проблему воспроизвести не удалось, то, вероятно, проблема связана с особенностями подключения к сервису конкретного пользователя. Для диагностики проблем такого рода можно воспользоваться обработкой «Диагностика качества подключения», встроенной в менеджер сервиса.

Рис.4 Обработка «Диагностика качества соединения»

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

• Соединение обладало высокой стабильностью (до версии технологической платформы 8.3.6 включительно факт неполучения ответа от сервера приводит к зависанию тонкого клиента)
• Соединение имело хорошую скорость (рекомендуется не менее 2 Мбит)
• Компьютер обладал достаточной производительностью. Конкретное значение определяется эмпирически, и зависит от типа браузера, использованного для выполнения теста; значение на скриншоте — 0.491 — означает хорошую производительность компьютера, в случае если оно получено при использовании Google Chrome. Значения более 1-1.5 сек (в случае использования Google Chrome) обычно указывают на недостаточную производительность клиентского компьютера.

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

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

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

Медленная работа определенной функциональности у определенных пользователей

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

• Получить максимально подробное описание проблемы от пользователя;
• Попробовать воспроизвести проблему на копии области пользователя. Если воспроизвести удалось, то выполнить анализ с помощью этой методики.
• Если воспроизвести не удалось, то настроить технологический журнал с событиями DBMSSQL (или другие в зависимости от используемой СУБД), CALL и SCALL.
• Попросить пользователя воспроизвести операцию, и засечь время начала выполнения и длительность операции по секундомеру.
  Также это можно выполнить самостоятельно на компьютере пользователя, если проблема воспроизводится «прямо сейчас», и пользователь согласен на удаленное подключение к его компьютеру.
• Если операция относится к числу ключевых, то уточнить точное время начала и окончания операции по данным замеров производительности
• Выяснить номер сеанса по данным журнала регистрации

Рис.5 Уточнение номера сеанса по журналу регистрации

Отфильтровать собранный технологический журнал по номеру сеанса и типу события, используя следующую команду:
cat /*/* | perl -n -e ‘if (/^\d\d:\d\d\.\d+/) <$event =

s/\n/

/g; print $event.»\n»; $event = «»;> $event .= $_; END;’ | grep «SessionID= » | grep «, ,» | sed ‘s/

/\n/g’ > .txt
где:

• — путь к каталогу с собранными технологическими журналами
• — номер сеанса, в котором выполнялась анализируемая операция
• — тип события (CALL, DBMSSQL или SDBL)

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

Посчитать суммарную длительность серверных вызовов (события CALL) и суммарное время выполнения запросов (DBMSSQL, SDBL), используя следующую команду:
cat | awk -F’-‘ ‘ END ;>’ | sort -rn > .txt
где — тип события (CALL, DBMSSQL или SDBL)

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

Источник