Другой взгляд на APDEX и подсистему "Оценка производительности"
Описание принципа работы подсистемы "Оценка производительности" из БСП, примеров использования, недостатках подсистемы, а также рассуждение о путях улучшения мониторинга производительности в системах 1С.
Отличная статья!
APDEX - попытка перевода субъективного мнения пользователя в какие-то цифры. Как и любая цифровизация страдает кучей допущений и упущений. На мой взгляд - красочный вид и помощь в сдаче работ - это как раз его основное предназначение.
(4) Я бы не назвал это чисто маркетинговым ходом. Всё-таки APDEX неплохо коррелирует с эксплуатационными характеристиками системы, и отклонение в APDEX вполне себе объективный показатель проблем.
Но ведь эта оценка является субъективной, в том плане, что приоритеты и целевое время операций определяеися бизнес-пользователями. По крайней мере должно.
С другой стороны есть объективные показатели работы системы: нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.
(6) Так для бизнеса как раз и важна "субъективная оценка пользователей". А вот уже непосредственно техническая эксплуатация должна проактивно собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.
но собирать объективные метрики и реагировать, чтобы APDEX оставался в установленных рамках.
Я согласен, но APDEX можно всегда "подогнать" под нужные цифры, то есть им можно манипулировать в свою пользу. Я к тому и веду, что все равно нужны объективные метрики, которые ни APDEX, ни подсистема "Оценка производительности" не смогут дать.
Альтернативные варианты это сбор метрик инфраструктуры, есть также платные решения для замера времени операций в конфигурациях, которые лишены многих перечисленных в статье недостатков, но называть их не буду. А то будет реклама.
нагрузка на сеть, CPU, диски, время выполнения операций в секундах и др.
можно, но вы столкнетесь с тем, что эти параметры не статичны и иногда изменяются в довольно широких диапазонах и тут встанет вопрос, какие значения брать, средние? Тогда любой пик сразу вызовет нарушение SLA, если взять пиковые значения, тогда есть риск просто пропустить аварию.
Или, оговорили, что нагрузка на проц не должна быть выше 90%, но прикол в том, что и 91% на скорости работы может никак не отразиться, т.е. мы имеем нарушение договоренностей без влияния.
Ок, берем время выполнения, описываем какое оно должно быть. А если одна операция из ста будет выше нормы? а если из тысячи, тоже превышение?
Спасибо автору за ликбез. Подсистемой никогда не пользовался, хотя постоянно на неё натыкаюсь в типовых и тп. Примерно так всё и представлял. Сплошной маркетинг. В бух3, кстати, регулярно сыпятся ошибки из-за этой подсистемы ;))
8.
Gilev.Vyacheslav
184020.02.19 10:48 Сейчас в теме
достаточно отказаться от оценки собранных времен через различные дополнительные формулы, а вручную оценивать собственно собранные времена, и делов то
неужели для этого надо статьи писать
(8) все, конечно, так, но и замеры могут быть неадекватными из-за ошибок и особенностей алгоритмов сбора в подсистеме.
Статья для полноты и целостности. А так можно было просто написать: "Не используйте APDEX и замеры времени БСП. Лучше использовать альтернативные решения для мониторинга.".
16.
Gilev.Vyacheslav
184020.02.19 17:45 Сейчас в теме
(10) странный вывод, наоборот, доработайте стандартную подсистему - выкорчуйте оттуда индексы, оставьте время
по поводу ошибок замеров - ну во первых есть два подхода:
1. по подписке
2. в явном виде вручную время До и время ПОСЛЕ
первый способ применяется на первом этапе "ознакомления", второй соответственно последовательно на втором этапе, когда общая картина ясна и нужно работать точечно
кроме того, классический апдекс собирает только сервер, красиво доработать код и собирать время на клиенте - это конечно больше усилий, но тогда можно поймать "белый экран", который на стороне сервера 1С часто не ловится вообще
(16) Думаю, что все кто плотно работает с подсистемой "Оценка производительности" допиливают ее под себя. Ниже в комментариях я давал пример.
>> Лучше использовать альтернативные решения для мониторинга
Тут я имел ввиду, что на рынке есть альтернатива подсистеме "Оценка производительности" от известной компании, название которой не скажу, а то сочтут за рекламу. Их решение не нагружает основную систему для записи статистических данных, а передает их в другое место.
Плюс как не допиливай БСПшное решение, некоторые проблемы все равно не решить:
1. Например, замер заканчивается "После записи" документа и вроде бы все хорошо, но клиентское приложение продолжает "думать". Такое может произойти, когда форма после записи отправляет оповещения другим формам, а те начинают делать свои дела.
2. Потерянные замеры также не решаются, то о чем писал в публикации.
3. Не все операции можно замерять с помощью ОП, например пролистывание динамического списка и другие встроенные в платформу действия.
В идеале, если бы замеры были встроены в саму платформу, тогда и контроль за ними был бы куда больше. Хотя замеры в платформе есть, но в виде технологического журнала. Но для APDEX его данные трудно использовать.
1. APDEX хорош как метод грубой оценки, потому что если APDEX покажет отлично/хорошо, то навряд ли пользователи вообще захотят тестов, и навряд ли тестами вы выйдете на обратные результаты. И наоборот - APDEX 0.5 то навряд ли дело в замерах производительности.
2. С точки зрения общения с непрофессионалами вообще незаменим, он оттуда и вырос. К фин директору вы не придете с простыней где время выполнения запроса в микросекундах. А тут все понятно - плохо. хорошо. отлично
Ключевые операции конечно надо очень хорошо подбирать чтобы все заработало как надо, а не просто с настройками по умолчанию включать.
В принципе любую вещь не помешает настроить перед включением в продакт.
Запустите ТЖ с настройками по умолчанию и через час не только ошибки будут сыпаться как тут говорят, а просто сервер устанет.
Пометив на удаление или сняв пометку - можно управлять запуском замера (не запускать - запускать).
Кроме того, если договориться, что во все существующие механизмы таким образом встраивать инициализацию и фиксацию - получается очень удобно. Нужно сделать замер - создал ключевую операцию, не нужно - удалил.
(14) делал подобное, но дополнительно была возможность замеров создания форм.
То есть замер начинался при создании на сервере, а заканчивался после открытия формы.
На скорость открытия формы практически не влияло.
Статья как минимум будет полезна тем кто решает - поможет ли им ОП или стоит рассмотреть альтернативные подходы.
Что касается технических деталей - то действительно - ОП в БСП можно докрутить, тут фантазия ограничивается лишь ресурсами для реализации задуманного. Как вариант можно прикрутить платформенные механизмы записи действий пользователей, в некоторых случаях это осуществимо достаточно просто. С каждой ситуацией нужно разбираться индивидуально и искать индивидуальные подходы. По мне так интересен подход использования интегральной оценки совместно с пооперационным apdex.
Тоже никогда не любил апдекс.
Я или использую гугл аналитикс фиксируя изменения в базе, или использую гугл аналитикс по анализу лога действий пользователей.
Так как показывает практика, что я могу, например ускорить отчет, который пользователь открывает 100 раз день с 10 секунд, до 5 секунд, что приемлемо.
В этом случае апдекс мне скажет - что все кул, ты вырулил. НО НИФИГА!
Ибо некие одаренные личности, для проверки остатка товара открывают чек, пробивают товар, заходят в него, открывают из него отчеты - отчет по остаткам, выбирают размер в отборах и строят его.
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%. А почему так делают люди, а потому что им предыдущие показали, что они так делали, и что тот отчет самый правильный, и не верьте отчету, который находится ПО БОЛЬШОЙ КНОПКЕ НА СТОЛЕ!
Хотя, принципиально - это один и тот же отчет. А не доверяли ему, так как когда то сохранили настройки в отборе левые, и все :)
Я просто к чему - все эти показатели, это что то из области фантастики, ибо мерять ими можно только те вещи, которые делаются теми людьми, которым разработчик может доверять, или полностью автоматизированные вещи, типо регламентов.
Т.е. по факту - проверка товара на остатке занимает не 10 секунд, а 30-40, и на фоне этого - ускорив отчет на 5 секунд, профит будет не в 2 раза, а всего на 10%.
а гугл аналитикс как тут поможет? Это пример из крайностей.
(28) а для оценки качества чего?
Вы какую цель ставите - оценить нечто и как то, или сделать чтобы люди работали быстрее и "правильнее".
Если вы хотите просто что то замерять - то точно там же, в переходах на экранах, или в сценариях - вы делаете замер производительности.
Подключите себе тестовый аккаунт и посмотрите что можно сделать, а что нельзя. Вот где реальность, вот где процедура вывода отчета на экран может зависить от мощности компа, на котором крутиться тонкий клиент. И все это можно отследить, разделить и проанализировать.
Приведу пример когда APDEX не хватает для понятия ситуации:
целевое время проведения документа "Х" = 10 сек,
все замеры попали в интервал 10.2 - 10.5 сек - APDEX равен 0.5, что "неприемлемо",
но превышение целевого времени 200-500 мс на самом деле не является проблемой для пользователя,
если он согласен на 10 сек, то 10.5 сек не будут проблемой.
Поэтому мы еще смотрим среднее, минимальное и максимальное.
- Алло! ИТ отдел? У нас жутко тормозит 1С, очередь уже на кассе.
- Что у вас тормозит конкретно. Что вы делаете?
- Ну реализацию проводим.
- Вот я смотрю по APDEX показатель 0,8. Это все очень хорошо. Что вы мне лапшу на уши вешаете идите работайте.
p.s. к сожалению усредненные данные порой показывают прекрасные результаты, а по факту у пользователей при некоторых неблагоприятных пересечений нагрузок действительно тормозит 1С.
(23)хотелось бы поддержать желание конкретики :) оцениваем укрупнено, а вот деталей не найти :( Заказ стоимостью мильон и 100 руб по любому будут разное время проводится. Но мы их усредним, и уже допустимый показатель....
Но если больной жалуется на боль, а мы ее не видим - это не компетенция больного, это наша ...
27.
Sergey.Noskov
110124.06.19 15:23 Сейчас в теме
1. APDEX не панацея, но без никак.
2. APDEX требует внедрения и сопровождения, как любой другой типовой учет. Включая какой-то универсальный замер, не ждите от него актуальной оценки. Особое внимание ключевому времени.
3. Шкала APDEX так же может кастомизироваться. Иногда и 0.9 это уже "плохо".