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

20.02.19

База данных - HighLoad оптимизация

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

Для начала

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

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

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

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

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

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

Что такое APDEX

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

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

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

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

Пользователь Номер сеанса 1С Дата записи Количество операций Среднее время выполнения (сек.)
Главный бухгалтер 19 15.01.2019 4:29:11 1 167,42
Главный бухгалтер 30 15.01.2019 6:47:36 1 3 199,88
Главный бухгалтер 46 15.01.2019 7:44:56 1 3 362,15
Заместитель гл. бухгалтера 58 15.01.2019 8:40:59 1 599,16
Заместитель гл. бухгалтера 61 15.01.2019 10:09:57 1 1 600,18
Главный бухгалтер 100 15.01.2019 12:34:49 1 160,86
Главный бухгалтер 36 16.01.2019 5:06:22 1 173,14
Главный бухгалтер 32 23.01.2019 9:51:05 1 1 981,29
Заместитель гл. бухгалтера 33 05.02.2019 9:21:07 1 965,88
Главный бухгалтер 25 08.02.2019 8:47:22 1 2 270,26
Разработчик 1С 27 08.02.2019 10:15:15 1 2 061,72
Итого 11 1 503,81

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

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.00 0.50 неприемлемо
0.50 0.70 очень плохо
0.70 0.85 плохо
0.85 0.94 хорошо
0.94 1.00 отлично

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замер времени

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

Автоматически созданная ключевая операция

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

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

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

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

 
 Что это за тяжелая операция из примеров

В типовых конфигурация начальный список ключевых операций достаточно большой - открытие различных форм, проведение документов и запись справочника, и многое многое другое. На скриншоте ниже показан пример анализа результатов замера, где рассчитано среднее время выполнения каждой ключевой операции и индекс производительности 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 мониторинг

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2387    spyke    25    

38

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7355    149    ZAOSTG    66    

95

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

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5766    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8588    ivanov660    6    

75

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    4999    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    15958    skovpin_sa    14    

98

Как эффективно настроить autovacuum в Postgres для 1С

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Бесплатно (free)

Кто не любит убирать мусор? Думаю, практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres, можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.

05.08.2023    4974    1CUnlimited    5    

51
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Hekeus 20.02.19 09:43 Сейчас в теме
Отличная статья!
APDEX - попытка перевода субъективного мнения пользователя в какие-то цифры. Как и любая цифровизация страдает кучей допущений и упущений. На мой взгляд - красочный вид и помощь в сдаче работ - это как раз его основное предназначение.
gubanoff; YPermitin; +2 Ответить
2. пользователь 20.02.19 09:47
(1) Спасибо!

Иногда Apdex хорош, но если нужен серьезный контроль производительности, то смысла в нем может быть немного.
life-wayfarer; +1 Ответить
3. genayo 20.02.19 09:50 Сейчас в теме
Целевые показатели APDEX могут быть зафиксированы в договоре на внедрение, и работы не будут приняты, пока они не будут достигнуты, например.
YPermitin; +1 Ответить
4. пользователь 20.02.19 10:01
(3) да, поэму эту методику в публикации я больше и называл как маркетинговый ход.

Вряд ли в договоре можно технические показатели зафиксировать, а APDEX без проблем :)
5. genayo 20.02.19 10:33 Сейчас в теме
(4) Я бы не назвал это чисто маркетинговым ходом. Всё-таки APDEX неплохо коррелирует с эксплуатационными характеристиками системы, и отклонение в APDEX вполне себе объективный показатель проблем.
Vladimir Litvinenko; AnderWonder; YPermitin; +3 Ответить
6. пользователь 20.02.19 10:38
(5) Я вас понимаю.

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

С другой стороны есть объективные показатели работы системы: нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.

Почему бы не опираться на них при аудите системы.
Дмитрий74Чел; +1 Ответить
11. genayo 20.02.19 11:02 Сейчас в теме
(6) Так для бизнеса как раз и важна "субъективная оценка пользователей". А вот уже непосредственно техническая эксплуатация должна проактивно собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.
12. пользователь 20.02.19 12:18
(11)
но собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.


Я согласен, но APDEX можно всегда "подогнать" под нужные цифры, то есть им можно манипулировать в свою пользу. Я к тому и веду, что все равно нужны объективные метрики, которые ни APDEX, ни подсистема "Оценка производительности" не смогут дать.

Альтернативные варианты это сбор метрик инфраструктуры, есть также платные решения для замера времени операций в конфигурациях, которые лишены многих перечисленных в статье недостатков, но называть их не буду. А то будет реклама.
bladeson; life-wayfarer; +2 1 Ответить
26. Sergey.Noskov 1375 24.06.19 15:10 Сейчас в теме
(6)
нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.

можно, но вы столкнетесь с тем, что эти параметры не статичны и иногда изменяются в довольно широких диапазонах и тут встанет вопрос, какие значения брать, средние? Тогда любой пик сразу вызовет нарушение SLA, если взять пиковые значения, тогда есть риск просто пропустить аварию.
Или, оговорили, что нагрузка на проц не должна быть выше 90%, но прикол в том, что и 91% на скорости работы может никак не отразиться, т.е. мы имеем нарушение договоренностей без влияния.
Ок, берем время выполнения, описываем какое оно должно быть. А если одна операция из ста будет выше нормы? а если из тысячи, тоже превышение?
7. sergathome 4 20.02.19 10:43 Сейчас в теме
Спасибо автору за ликбез. Подсистемой никогда не пользовался, хотя постоянно на неё натыкаюсь в типовых и тп. Примерно так всё и представлял. Сплошной маркетинг. В бух3, кстати, регулярно сыпятся ошибки из-за этой подсистемы ;))
wowik; YPermitin; +2 Ответить
9. пользователь 20.02.19 10:53
(7) зато отчеты красивые :)
sergathome; +1 Ответить
8. Gilev.Vyacheslav 1910 20.02.19 10:48 Сейчас в теме
достаточно отказаться от оценки собранных времен через различные дополнительные формулы, а вручную оценивать собственно собранные времена, и делов то
неужели для этого надо статьи писать
DrSender; Silenser; blackhole321; Vovan58; +4 Ответить
10. пользователь 20.02.19 10:56
(8) все, конечно, так, но и замеры могут быть неадекватными из-за ошибок и особенностей алгоритмов сбора в подсистеме.

Статья для полноты и целостности. А так можно было просто написать: "Не используйте APDEX и замеры времени БСП. Лучше использовать альтернативные решения для мониторинга.".
for_sale; +1 Ответить
16. Gilev.Vyacheslav 1910 20.02.19 17:45 Сейчас в теме
(10) странный вывод, наоборот, доработайте стандартную подсистему - выкорчуйте оттуда индексы, оставьте время
по поводу ошибок замеров - ну во первых есть два подхода:
1. по подписке
2. в явном виде вручную время До и время ПОСЛЕ
первый способ применяется на первом этапе "ознакомления", второй соответственно последовательно на втором этапе, когда общая картина ясна и нужно работать точечно

кроме того, классический апдекс собирает только сервер, красиво доработать код и собирать время на клиенте - это конечно больше усилий, но тогда можно поймать "белый экран", который на стороне сервера 1С часто не ловится вообще
Vovan58; YPermitin; +2 Ответить
18. пользователь 20.02.19 19:24
(16) Думаю, что все кто плотно работает с подсистемой "Оценка производительности" допиливают ее под себя. Ниже в комментариях я давал пример.

>> Лучше использовать альтернативные решения для мониторинга
Тут я имел ввиду, что на рынке есть альтернатива подсистеме "Оценка производительности" от известной компании, название которой не скажу, а то сочтут за рекламу. Их решение не нагружает основную систему для записи статистических данных, а передает их в другое место.

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

В идеале, если бы замеры были встроены в саму платформу, тогда и контроль за ними был бы куда больше. Хотя замеры в платформе есть, но в виде технологического журнала. Но для APDEX его данные трудно использовать.
13. capitan 2461 20.02.19 16:01 Сейчас в теме
1. APDEX хорош как метод грубой оценки, потому что если APDEX покажет отлично/хорошо, то навряд ли пользователи вообще захотят тестов, и навряд ли тестами вы выйдете на обратные результаты. И наоборот - APDEX 0.5 то навряд ли дело в замерах производительности.
2. С точки зрения общения с непрофессионалами вообще незаменим, он оттуда и вырос. К фин директору вы не придете с простыней где время выполнения запроса в микросекундах. А тут все понятно - плохо. хорошо. отлично

Ключевые операции конечно надо очень хорошо подбирать чтобы все заработало как надо, а не просто с настройками по умолчанию включать.
В принципе любую вещь не помешает настроить перед включением в продакт.
Запустите ТЖ с настройками по умолчанию и через час не только ошибки будут сыпаться как тут говорят, а просто сервер устанет.
Sergey.Noskov; YPermitin; +2 Ответить
14. Dach 371 20.02.19 16:35 Сейчас в теме
Мы слегка доработали в своей конфигурации инициализацию замеров.

Есть вот такая функция

ИмяКлючевойОперацииЗамераПроизводительности


Используем так:

Перем ВремяНачалаЗамера;
ВремяНачалаЗамера = 0;

Процедура модуля объекта документа ПередЗаписью


//Замер производительности инициализация
	ИмяОперацииЗамераПроизводительности = ОбщегоНазначения.ИмяКлючевойОперацииЗамераПроизводительности(ЭтотОбъект, СтрЗаменить(Строка(РежимЗаписи), " ", ""));
	ВремяНачалаЗамера = 0;
	
	Если ЗначениеЗаполнено(ИмяОперацииЗамераПроизводительности) Тогда 
		ВремяНачалаЗамера = ОценкаПроизводительности.НачатьЗамерВремени();
	КонецЕсли;	
	//Замер производительности инициализация

Показать


Процедура ПриЗаписи


//Замер производительности фиксация
	Если СтрНайти(ИмяОперацииЗамераПроизводительности, ".Запись") > 0 И ВремяНачалаЗамера <> 0 Тогда
		ОценкаПроизводительности.ЗакончитьЗамерВремени(ИмяОперацииЗамераПроизводительности, ВремяНачалаЗамера, Товары.Количество(), "РТиУ " + Номер + " от " + Строка(Дата));
	КонецЕсли;	
	//Замер производительности фиксация

Показать


Процедура ОбработкаПроведения


//Замер производительности фиксация
	Если ВремяНачалаЗамера <> 0 Тогда
		ОценкаПроизводительности.ЗакончитьЗамерВремени(ИмяОперацииЗамераПроизводительности, ВремяНачалаЗамера, Товары.Количество(), "РТиУ " + Номер + " от " + Строка(Дата));
	КонецЕсли;	
	//Замер производительности фиксация

Показать


В справочнике "Ключевые операции" созданы элементы с наименованием:

Документ.РеализацияТоваровУслуг.Проведение
Документ.РеализацияТоваровУслуг.Запись

Аналогично для любых произвольных алгоритмов

ПроизвольныйАлгоритм.СформироватьПрайсЛист

Пометив на удаление или сняв пометку - можно управлять запуском замера (не запускать - запускать).
Кроме того, если договориться, что во все существующие механизмы таким образом встраивать инициализацию и фиксацию - получается очень удобно. Нужно сделать замер - создал ключевую операцию, не нужно - удалил.
afk; Дмитрий74Чел; YPermitin; +3 Ответить
15. пользователь 20.02.19 17:23
(14) делал подобное, но дополнительно была возможность замеров создания форм.
То есть замер начинался при создании на сервере, а заканчивался после открытия формы.
На скорость открытия формы практически не влияло.

А так + :)
17. Shmell 532 20.02.19 18:51 Сейчас в теме
Статья как минимум будет полезна тем кто решает - поможет ли им ОП или стоит рассмотреть альтернативные подходы.
Что касается технических деталей - то действительно - ОП в БСП можно докрутить, тут фантазия ограничивается лишь ресурсами для реализации задуманного. Как вариант можно прикрутить платформенные механизмы записи действий пользователей, в некоторых случаях это осуществимо достаточно просто. С каждой ситуацией нужно разбираться индивидуально и искать индивидуальные подходы. По мне так интересен подход использования интегральной оценки совместно с пооперационным apdex.
YPermitin; +1 Ответить
19. DitriX 2091 21.02.19 00:04 Сейчас в теме
Тоже никогда не любил апдекс.
Я или использую гугл аналитикс фиксируя изменения в базе, или использую гугл аналитикс по анализу лога действий пользователей.
Так как показывает практика, что я могу, например ускорить отчет, который пользователь открывает 100 раз день с 10 секунд, до 5 секунд, что приемлемо.
В этом случае апдекс мне скажет - что все кул, ты вырулил. НО НИФИГА!
Ибо некие одаренные личности, для проверки остатка товара открывают чек, пробивают товар, заходят в него, открывают из него отчеты - отчет по остаткам, выбирают размер в отборах и строят его.
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%. А почему так делают люди, а потому что им предыдущие показали, что они так делали, и что тот отчет самый правильный, и не верьте отчету, который находится ПО БОЛЬШОЙ КНОПКЕ НА СТОЛЕ!
Хотя, принципиально - это один и тот же отчет. А не доверяли ему, так как когда то сохранили настройки в отборе левые, и все :)

Я просто к чему - все эти показатели, это что то из области фантастики, ибо мерять ими можно только те вещи, которые делаются теми людьми, которым разработчик может доверять, или полностью автоматизированные вещи, типо регламентов.
YPermitin; +1 Ответить
20. пользователь 21.02.19 05:29
22. DonAlPatino 176 26.02.19 11:38 Сейчас в теме
(19)А можно какие-то ссылки на тему прикрутить гугл аналитикс к 1С? Как-то даже в голову не приходило что так можно...
Дмитрий74Чел; +1 Ответить
24. Sergey.Noskov 1375 24.06.19 15:00 Сейчас в теме
(19)
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%.
а гугл аналитикс как тут поможет? Это пример из крайностей.
25. DitriX 2091 24.06.19 15:08 Сейчас в теме
(24) в гугл аналитикс вы можете построить юзер строрис. Типо такого как на картинке, и вы можете отследить - как туда попал пользователь.
28. Sergey.Noskov 1375 24.06.19 15:26 Сейчас в теме
(25) отследить да, но это анализ, а для оценки качества?
29. DitriX 2091 24.06.19 15:34 Сейчас в теме
(28) а для оценки качества чего?
Вы какую цель ставите - оценить нечто и как то, или сделать чтобы люди работали быстрее и "правильнее".
Если вы хотите просто что то замерять - то точно там же, в переходах на экранах, или в сценариях - вы делаете замер производительности.

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

https://analytics.google.com/analytics/web/demoAccount
21. geron4 193 22.02.19 08:59 Сейчас в теме
Приведу пример когда APDEX не хватает для понятия ситуации:

целевое время проведения документа "Х" = 10 сек,
все замеры попали в интервал 10.2 - 10.5 сек - APDEX равен 0.5, что "неприемлемо",
но превышение целевого времени 200-500 мс на самом деле не является проблемой для пользователя,
если он согласен на 10 сек, то 10.5 сек не будут проблемой.
Поэтому мы еще смотрим среднее, минимальное и максимальное.
Прикрепленные файлы:
YPermitin; +1 Ответить
23. FreeArcher 158 20.06.19 13:54 Сейчас в теме
- Алло! ИТ отдел? У нас жутко тормозит 1С, очередь уже на кассе.
- Что у вас тормозит конкретно. Что вы делаете?
- Ну реализацию проводим.
- Вот я смотрю по APDEX показатель 0,8. Это все очень хорошо. Что вы мне лапшу на уши вешаете идите работайте.

p.s. к сожалению усредненные данные порой показывают прекрасные результаты, а по факту у пользователей при некоторых неблагоприятных пересечений нагрузок действительно тормозит 1С.
stepan_s; YPermitin; +2 Ответить
30. stepan_s 05.09.19 06:51 Сейчас в теме
(23)хотелось бы поддержать желание конкретики :) оцениваем укрупнено, а вот деталей не найти :( Заказ стоимостью мильон и 100 руб по любому будут разное время проводится. Но мы их усредним, и уже допустимый показатель....
Но если больной жалуется на боль, а мы ее не видим - это не компетенция больного, это наша ...
27. Sergey.Noskov 1375 24.06.19 15:23 Сейчас в теме
1. APDEX не панацея, но без никак.
2. APDEX требует внедрения и сопровождения, как любой другой типовой учет. Включая какой-то универсальный замер, не ждите от него актуальной оценки. Особое внимание ключевому времени.
3. Шкала APDEX так же может кастомизироваться. Иногда и 0.9 это уже "плохо".
31. houpl 29.09.21 09:05 Сейчас в теме
Очень подробно, спасибо за статью.
Оставьте свое сообщение