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

Херня а не методика

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

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

Операция является критичной для бизнес-процессов заказчика.
При недостаточной производительности системы на этой операции могут происходить потери для бизнеса заказчика.
Операция выполняется одновременно значительным количеством пользователей (более 10).
Имеются жалобы пользователей на производительность на этой операции.
(с) https://its.1c.ru/db/metod8dev/content/5807/hdoc

Обрати внимания на последний пункт. Если документ проводиться гновенно/отчет строиться быстро, то хоть в топ 1 по ЖР, но каким местом она критическая?

И да зачем вам это? APDEX бесполезен и неинформативен. Единственное для чего он нужен чтобы впарить свои услуги по оптимизации

Спасибо за ответ! В данный момент стоит задача снять показатели производительности системы. Клиент-серверный вариант. Сервера и sql уйдет в ведение другого отдела и при падении производительности нужно будет аргументированно спорить по этому поводу. Возможно использовать методику отличную от APDEX?

А причем тут 1С?

И APDEX не подходит для отслеживания динамики

Ну вот смотри у тебя 2 человека которые колотят только ПКО и РКО. Максимум 3 документа в день. Ты настроил ключевые операция и снял показания.

Через год там уже 58 человек 12 фирм приходы, расходы, ВЭД, комиссия... А у тебя всего 2 ключевые операции ПКО и РКО. Т.е. кто будет вносить изменения и корректировать?

К тому же ну упал индекс и что? Сеть тормозит? Добавили 100500 пользователей? Или кто то кривой код дописал по рассылки прайса каждый день для 500 тысяч клиентов с фиксацией результата переписки в базе. И из-за этого "база висит".

Т.е. что тебе даст твой зафиксированный в прошлом году APDEX?

Aleksey, можешь что-то порекомендовать? Необходимо иметь аргументы в споре с DBA. Чтоб не было такого- у меня все зае-сь, это у вас в 1с проблемы, сами разбирайтесь.

Нет, не мой профиль. Я обычный фикси, мне некого "перекладывать" ответственность за производительность. Поэтому хз какие методики актуальны.
К тому же DBA пофиг на твои отчеты из 1С. у него есть свои данные . Так что бесполезно ему тыкать в 1С. "Сеть и сервера работает? Работает. А что там в ваших 1С происходят пусть программисты разбираются"

(0) ключевые - это наиболее важные... Если у тебя приход будет проводиться 5 мин - переживет кладовщик, а если ты 5 мин будешь счёт покупателю выписывать - это не хорошо! И ЖР тебе тут не помощник.

(9) >Нет, не мой профиль

Однако утверждать, что "APDEX бесполезен и неинформативен" смелость имеешь. :)

(4) >нужно будет аргументированно спорить по этому поводу

Зачем спорить? Если сервер будет в ведении другого отдела, то что бы с ним не случилось, это будет их головная боль, не так ли?

(6) Чой-та ржу.

(7) > Через год
Не мелочись, возьми сразу десяток лет.

(9) > Поэтому хз какие
Но повыступать любишь, да.

Зачем спорить? Если сервер будет в ведении другого отдела, то что бы с ним не случилось, это будет их головная боль, не так ли?


Не совсем) Чтобы понять что с ним что-то случилось нужно метрики какие-то иметь. К примеру тому же DBA сделать заявку, мол раньше операция занимала 1мин, теперь 20.

(13)  см (7). Бизнес постоянно меняется. И то что раньше было не нужно - теперь нужно. Т.е. нужно постоянно перетрахивать ключевые операции на тему приоритетов и целевого времени. Кто это будет делать? Плюс по нему невозможно понять причину падения. К примеру вчера были документы максимум 10 строк и проводились за 1 секунду. Сейчас в документах минимум 2500 строк, и уже даже в 3 секунды не влазиют. Кто виновать?  SQL? Сеть? Сервера? Или просто задано некорректно целевое время?
Поэтому я и говорю что для отслеживания динамики он не подходит. Так как я вижу что индекс падает и начинаю тыкать DBA что смотри вчера было вот такая цифра сегодня вот такая, это у тебя проблем. Хотя на самом деле железо тут не причем

Или к примеру была девочка которая сначала ставила отборы, потом формировала отчет максимум за 1 месяц. И индексы показывали 0,95
Пришла новая бухша, которая не любит ставит отчеты, и всегда ставит период минимум 10 лет, и дальше выгружает в ексель и там ковыряет. Логично что индексы в этом случае у нас улетят в ад, так как за за 1 секунды такой отчет не сформируешь. И она будет выть что все плохо и тормозит?
И что покажет твоя оценка? - Ну тут как повезет. Так как по методике пики выбрасываются, а значит если таких отчетов будет немного в основной массе, то ты ничего не увидишь, ибо падение индекса будет незначительно, так как максимум не учитывается. Если таких отчетов будет большинство, то индексы будут на уровне плинтуса, что опять нам ни говорит ровным счетом ничего о том что делать и кто виноват.

(18) для отчетов апдекс конечно хитрая вещь.
как минимум нужен коэфф периода

Не,тут девочек никаких не предусматривается в анализе. Ситуация будет такая:
Сняли метрики какие то(пока думаем апдекс), запомнили.
Прошло время база стала тормозить.
Повторно сняли метрики и видим разницу.
Обращаемся к DBA,показываем первичные и вторичные замеры-пусть разбирается, пока не вернется к первичным показателям. Ну как-то так.

(20) Я бы на месте DBA послал бы в пешее эротическое путешествие. И был бы прав

Берем пустею базу снимаем показатель (например формирование  карточку счета 41 за год)
Через год формируем эту же карточку за год в базе куда активно бились данные и видим сильное падение производительности. Идем к DBA и получаем от него бан (или в жбан, как повезет), ибо у него все хорошо, проблема на вашей стороне

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

И он не подходит для сравнения разных баз (сейчас и через год)

(22) если получаем падение, то это значит что сервер не справляется.
в апдексе же задается целевое время.
допустим карточка должна формироваться за 5 сек.
в начале просто было сильно лучше, но ппдекс этого не покажет

подбор целеаого времени - это такая очень субъективная операция

Погоняй тест Гилева, зафиксируй результаты (хотя они там сами фиксируются, можно почту свою указать как идентификатор).
Это как раз тест железа, без привязки к "программистам".

Если потом показатели упадут будет тебе агрумент

Про этот тест речь?

http://www.gilev.ru/sqlsize/

(27) Ты где был все это время?

Я хз в каком лесу надо жить чтобы тест Гилева не знать http://www.gilev.ru/tpc1cgilv/

Есть еще https://infostart.ru/public/173394/

Спасиб! Ушел изучать