Каталог решений - Другой взгляд на 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;
	ИмяОперации = "ПримерЗамераНаКлиенте";
	// Включаем отложенную запись результатов замера
	// Если передать "Ложь", то результаты замеров нужно
	// будет фиксировать самостоятельно
	АвтоЗавершение = Истина;
	ВремяНачалаОперации = ОценкаПроизводительностиКлиент.НачатьЗамерВремени(АвтоЗавершение, ИмяОперации);
	
	// Нагружаем клиентскую машину, экономим ресурсы сервера :)
	ОченьТяжелаяОперацияНаКлиенте();
	
	// Можно завершить замер тут, но оставим эту работу БСП
	//ОценкаПроизводительности.ЗакончитьЗамерВремени(
	//	ИмяОперации, 
	//	ВремяНачалаОперации, 
	//	ВесЗамера, 
	//	"Пример замера на клиенте");

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