Другой взгляд на APDEX и подсистему "Оценка производительности"

Для начала

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

Казалось бы, что тут дальше рассказывать? Уже было множество публикаций на эту тему, зачем еще одна? Сегодня мы постараемся коснуться основ методики APDEX, а также рассмотрим ее реализацию в БСП. Но самая интересная часть будет в рассмотрении ее слабых сторон и возможных решений. Мы коснемся таких вопросов как:

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

Для ярых сторонников этой подсистемы сразу предупреждаю — все, что будет сказано ниже, лишь мнение автора, и оно может не совпадать с Вашей точкой зрения. Готов к дискуссии в комментариях, но никакого насилия! 🙂

В статью добавлена щепотка юмора и самоиронии. Никого высмеивать целью не ставилось.

Еще раз повторяю — я не враг APDEX и подсистемы "Оценка производительности". Я их хороший друг!

Что такое APDEX

По этой теме очень много материала, ведь APDEX — это международный стандарт оценки производительности корпоративных информационных систем. Фирма "1С" рекомендует эту методику. Вопросы по ней есть в экзамене "Эксперт по технологическим вопросам", а подсистема "Оценка производительности" из Библиотеки Стандартных Подсистем (БСП) встроена в большое количество типовых конфигураций.

Основное преимущество данной методики — это простой результат, который очень легко интерпретировать. Её использование начинается со следующих простых шагов:

1. Поскольку APDEX ориентирован на потребности бизнеса, то совместно с ним определяются:
   • Список критичных бизнес-операций в системе, которые необходимо отслеживать.
   • Приоритет каждой операции
   • Целевое время отклика по каждой из них
2. Старт замеров времени выполнения каждой операции для более полной статистики
3. Анализ и интерпретация полученных результатов

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

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

APDEX = (NS + NT/2)/N, где 

• T — целевое время ключевой операции (600 секунд для этого примера)
• N – общее количество выполнений операции (по нашим данным их 11)
• NS – количество выполнений с временем отклика от 0 до Т (это данные сеансов 1С: 19, 58, 100, 26. Итого 4 замера)
• NT – количество выполнений с временем отклика от T до 4T (время выполнения от 600 до 2400, это сеансы 1С: 61, 32, 33, 25, 27. Итого 5 замеров)

В нашем случае расчет будет таким:

APDEX  = (4 + 5/2)/11 = 0,59

Но что это значит? По методике APDEX полученный индекс производительности можно интерпретировать как качественную оценку по следующей шкале.

Полученный индекс 0.59 говорит об очень плохом уровне производительности для операции "Закрытие месяца (перепроведение документов)". Пора предложить клиенту услуги по оптимизации! Почему именно эта операция является столь критичной? Бизнес так решил, ему виднее!

Пример очень простой, даже примитивный. Но он должен показать основу расчета индекса производительности APDEX. Более подробную информацию можно прочитать на ИТС, сайте Вячеслава Гилева или в Wiki.

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

Возможно, даже в договоре в качестве результатов работ по оптимизации зафиксировано не целевое время, а индекс производительности APDEX!

Пройдемте дальше.

Решение из БСП

Теперь рассмотрим более приземленную тему — как это реализовано в конфигурации? Мы будем рассматривать подсистему "Оценка производительности" из БСП версии 3.0. Данная версия может значительно отличаться от своих предшественников, но т.к. она включается в новые релизы конфигураций свой выбор остановим именно на ней. Тем более принцип ее работы не менялся уже многие годы.

Первое, что мы сделаем — установим в конфигураторе отбор по подсистеме "СтандартныеПодсистемы.ОценкаПроизводительности". Перед нами предстанет примерно такая картина.

Уоу! Так много объектов, но не теряйтесь! В первую очередь посмотрите на перечисление "УровниПроизводительности", значения которого совпадают с общей логикой распределения значений индекса производительности APDEX (см. таблицу выше). В справочнике "Ключевые операции" хранится список операций и их настройки (Имя операции, приоритет в виде числа, целевое время ключевой операции в секундах и некоторые другие характеристики), то есть все то, что необходимо для расчета этого индекса.

С недавних (или почти недавних) пор появилось разделение замеров времени на технологические и обычные (если так можно выразиться). Технологические — это те ключевые операции, которые явно не относятся к бизнесу. Например, к последним можно отнести замеры различных обработчиков обновления при "накатке" релизов и другие служебные операции. Обычные ключевые операции — это как-раз то, что нам нужно, так как относится к работе бизнеса. Это то, что нам следует замерять и анализировать.

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

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

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

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

 // Фиксируем время начала операции
ВесЗамера = 1;
ИмяОперации = "ПримерЗамераНаСервере";
ВремяНачалаОперации = ОценкаПроизводительности.НачатьЗамерВремени();

// Делаем что-то невообразимо тяжелое
ОченьТяжелаяОперацияНаСервере();

// Фиксируем результат замера
ОценкаПроизводительности.ЗакончитьЗамерВремени(
ИмяОперации,
ВремяНачалаОперации,
ВесЗамера,
"Просто сделаем замер");

После этого в регистре "Замеры времени" сразу же появится запись о времени выполнения операции.

В справочнике "Ключевые операции" автоматически добавится новый элемент справочника.

При этом вручную ее создавать не пришлось, система сделала все за нас. Останется только скорректировать приоритет, целевое время и допустимый уровень производительности, чтобы в дальнейшем посчитать APDEX. На сбор самой статистики эти параметры никак не влияют.

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

 ВесЗамера = 1;
ИмяОперации = "ПримерЗамераНаКлиенте";
// Включаем отложенную запись результатов замера
// Если передать "Ложь", то результаты замеров нужно
// будет фиксировать самостоятельно
АвтоЗавершение = Истина;
ВремяНачалаОперации = ОценкаПроизводительностиКлиент.НачатьЗамерВремени(АвтоЗавершение, ИмяОперации);

// Нагружаем клиентскую машину, экономим ресурсы сервера :)
ОченьТяжелаяОперацияНаКлиенте();

// Можно завершить замер тут, но оставим эту работу БСП
//ОценкаПроизводительности.ЗакончитьЗамерВремени(
// ИмяОперации,
// ВремяНачалаОперации,
// ВесЗамера,
// "Пример замера на клиенте");

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

&НаКлиентеНаСервереБезКонтекста
Процедура Ожидание(КоличествоСекунд)

ОжидатьДо = ТекущаяДата() + КоличествоСекунд;
Пока ТекущаяДата() <= ОжидатьДо Цикл
// Ничего не делаем и просто используем CPU впустую
// !!! Только на рабочей базе не используйте.
КонецЦикла;

КонецПроцедуры

&НаКлиенте
Процедура ОченьТяжелаяОперацияНаКлиенте()

Ожидание(10);

КонецПроцедуры

&НаСервере
Процедура ОченьТяжелаяОперацияНаСервере()

Ожидание(10);

КонецПроцедуры

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

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

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

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

Большие и не очень недостатки

Несмотря на столь интересный функционал по замерам времени выполнения операций, сам подход по использованию APDEX имеет серьезные недостатки. А техническая реализация подсистемы "Оценка производительности" в БСП имеет ряд проблем, которые потенциально могут сильно исказить собираемую статистику. Далее пройдемся по проблемным местам, вдруг что можно придумать.

Организационные проблемы

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

На практике же все происходит иначе. Когда встает вопрос составления перечня ключевых операций обычно менеджеры ИТ-проектов или технические специалисты предлагают уже готовый перечень этих самых операций. Со стороны клиента лишь остается определить приоритеты и целевое время, но и тут не все так радужно. Частый ответ на вопрос "Какое целевое время установим для этой ключевой операции?" это "Как можно скорее!". И тут снова начинается игра в "подгони целевое время под текущее" с тем смыслом, чтобы можно было оптимизировать операцию без больших трудозатрат и при этом еще и заказчик будет доволен.

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

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

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

В этом свете APDEX — это лишь маркетинг, чтобы лучше продавать услуги по оптимизации или рекламировать высокопроизводительные информационные системы с лозунгом "Средний APDEX выше 0.75 на всех проектах!". По мне лучше убрать всю эту "мишуру" и вернуться к замерам в старых добрых секундах с мониторингом динамики изменения показателей.

Слишком много допущений

Что значит индекс производительности APDEX равный 0.75 или 0.44? Значит он только одно — субъективное мнение пользователей системы о качестве ее работы. Конечно, пользователям не важно что именно в системе сломалось, важен конечный результат. Но мониторинг важен для ИТ-службы!

Почему индекс стал 0.44? Тормозит сеть? В новом релизе сделали неоптимальный запрос и положили базу? Или может так и должно работать и это просто тяжелая операция? А может пользователь просто случайно указал период в отчете 10 лет вместо недели и ожидал быстрого формирования?

APDEX не дает ответом что именно в информационной системе происходит, какие операции работают медленно, а какие быстро. Он просто отражает субъективное мнение бизнеса и не более того. Да, он может быть пунктом в договоре об оказании услуг или каким-то образом отражен в SLA, но решить какие-то конкретные проблемы он не сможет.

APDEX не учитывает динамику

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

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

Большие погрешности в измерениях

Формулу расчета мы уже видели. Напомню, что индекс производительности APDEX рассчитывается как соотношение количества операций с приемлемой скоростью к общему количеству операций. Приемлемыми операциями выступают все те что выполнились с целевой скоростью, а также плюс половина операций, которая выполнилась меньше чем за время, в 4 раза превышающее целевое. Так отбрасываются аномальные замеры операций, длительность которых значительно отличаются. А это уже может сильно исказить результат.

Например, Вы розничная компания с десятками филиалов по всей стране. В каждом регионе у вас несколько филиалов и для контроля работы системы Вы анализирует показатели APDEX по регионам. В одном регионе 5 филиалов, на одном из которых, допустим, проблемы с сетью. Рассчитывая индекс производительности может оказаться так, что как-раз эти аномалии в одном из филиалов будут отброшены и Вы получите хороший показатель. Чего этот филиал так жалуются, работать не хотят? 🙂

Также для редких операций, например, закрытие месяца, считать APDEX вообщем-то бессмысленно, т.к. данных будет очень мало. Разве что считать за 10 лет, но есть ли в этом смысл?

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

1. При возникновении ошибки во время замера на сервере его результат не будет зафиксирован.
2. При замерах на клиенте, если включено автоматическое завершение замера, могут быть интересные ситуации:
   • После начала замера появилось модальное окно и пока оно не будет закрыто, замер не будет завершен.
   • Замер стартует перед проведением документа на клиенте. Если во время проведения возникла ошибка, то замер будет остановлен после закрытия ошибки пользователем. А это может быть +5000 к длительности операции!
   • Замер не включает в себя никакой дополнительной информации о замере, то есть не будет понятно где операция больше всего выполнялась. А это могло бы помочь определить узкое место — слабый компьютер у сотрудника, сеть "тормозит" или на сервере баз данных что-то пошло не так.

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

 ВесЗамера = 1;
ИмяОперации = "ПримерЗамераНаКлиенте";

АвтоЗавершение = Истина;
ВремяНачалаОперации = ОценкаПроизводительностиКлиент.НачатьЗамерВремени(АвтоЗавершение, ИмяОперации);

// Нагружаем клиентскую машину, экономим ресурсы сервера :)
ОченьТяжелаяОперацияНаКлиенте();

// Пока пользователь не закроет окно об ошибке
// система будет считать, что замер времени выполнения продолжается.
ВызватьИсключение "И пусть весь Мир подождет!";

"Но ошибка это исключительная ситуация" — обычно так отвечают на это. Да, это так, но ошибки случаются у всех и предсказать много их будет или мало нельзя. Так можно ли доверять статистике замеров?

Потерянные замеры

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

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

Влияние на производительность и обслуживание

Да, Вы не ослышались! Контроль производительности с помощью замеров влияет на производительность!

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

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

Ну и стоит упомянуть, что если фиксация результата замера выполняется сразу же, то операция записи в регистр сведений все же может увеличить время выполнения операции. Конечно, это может показаться несущественным  — 0.05 секунды на запись результатов замера. Но если операций 1000, десятки или сотни тысяч. Тут уже может оказаться, что подсистема "Оценка производительности" Вам не подходит.

Сложность интеграции

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

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

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

Неужели все так плохо

Конечно, нет! Если Вы дочитали до этой строчки, то, возможно, Вы считаете меня противником APDEX и подсистемы "Оценка производительности", но это не так. На самом деле использую ее до сих пор, замеряю время выполнения операций и выполняю мониторинг системы. Зачем же тогда все это?

Все просто, я лишь хотел донести эти мысли:

• APDEX — это лишь вершина айсберга, с помощью которой можно в красочном виде предоставить бизнесу информацию о состоянии системы, но при этом ничего не объясняя (ну или почти не объясняя).
• APDEX может выступать в качестве маркетинговой составляющей при оказании услуг оптимизации производительности или продаже какого-либо продукта.
• Подсистема "Оценка производительности" из состава БСП полезна для сбора статистики выполнения операций, но имеет ряд существенных недостатков:
  • Потенциально большие погрешности в замерах
  • Потеря данных о замерах производительности
  • Влияние на производительность и операции обслуживания базы данных
  • Дополнительные требования к дисковому пространству или к очистке устаревших данных (такая возможность есть в подсистеме с помощью регл. задания).
  • Необходимость в дополнительных трудозатратах для добавления новых ключевых операций и сопровождения связанных с этим изменений.
• Для контроля производительности и стабильности системы APDEX’а и замеров в БСП недостаточно, нужен полноценный мониторинг инфраструктуры, СУБД, сервера 1С, клиентских машин пользователей и других составляющих.
• Производительность нужно измерять в конкретных цифрах и с учетом динамики изменений, а не в попугаях.

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

Другие ссылки

Тема замеров времени по методике APDEX достаточно часто обсуждалась как на Инфостарт, так и за его пределами. Вот некоторые материалы по данной теме:

• Оценка интегральной производительности системы по методике APDEX на ИТС

• Методика APDEX – стандарт оценки производительности корпоративных приложений на gilev.ru

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

• APDEX и оценка производительности стандартными средствами 1С от Евгения Золотарева

• Следим за производительностью системы. APDEX, PowerShell, PRTG от DDens Rema

• Многопоточное тестирование производительности по методике APDEX (управляемые формы) от Андрея Капитонова

• Определение целевого времени Т по известному APDEX от МороЗ