«1С тормозит» — самая бесполезная формулировка в мире. Что тормозит? Для кого? Насколько? По сравнению с чем? Без цифр разговор о производительности — гадание на кофейной гуще.
APDEX (Application Performance Index) — метрика, которая превращает субъективное «тормозит» в число от 0 до 1. Встроена в платформу 1С начиная с версии 8.3.10. Используется единицами.
Что такое APDEX и зачем он нужен
APDEX — стандарт индустрии, не изобретение 1С. Формула простая. Берём все операции за период. Делим на три группы:
Satisfied — операция выполнилась быстрее целевого порога T. Пользователь доволен.
Tolerating — операция выполнилась медленнее T, но быстрее 4T. Пользователь терпит.
Frustrated — операция выполнилась дольше 4T. Пользователь страдает.
APDEX = (Satisfied + Tolerating/2) / Total. Результат от 0 до 1. Выше 0.94 — отлично. 0.85-0.94 — хорошо. 0.7-0.85 — удовлетворительно. Ниже 0.5 — неприемлемо.
Одно число. Смотришь на него и понимаешь: система работает нормально или нет. Без длинных отчётов, без субъективных оценок.
Где взять APDEX в 1С
Два источника. Первый — Центр контроля качества (ЦКК). Включается на сервере 1С, собирает метрики автоматически. Есть встроенные дашборды. Минус — ЦКК сам потребляет ресурсы, и на слабых серверах может добавить нагрузки.
Второй — технологический журнал. Событие TIMED. Фиксирует каждую операцию с длительностью. Из лога можно вычислить APDEX самостоятельно. Минус — нужно парсить текстовые логи, что требует скриптов или сторонних инструментов.
Для начала рекомендую ЦКК. Настройка за час, результат сразу виден. Технологический журнал — для глубокого анализа, когда нужно разобраться в конкретных операциях.
Третий вариант — собрать метрики самостоятельно через HTTP-сервис в 1С. При каждом ключевом действии (проведение документа, формирование отчёта, открытие формы) засекать время и отправлять в Prometheus. APDEX считает Grafana. Это самый гибкий вариант, но требует доработки конфигурации.
Какие пороги ставить
Целевой порог T — ключевой параметр. Поставите слишком маленький — APDEX всегда будет низким, и метрика потеряет смысл. Слишком большой — APDEX всегда 1.0, и вы не увидите деградацию.
Наши рекомендации по типам операций:
Открытие формы документа: T = 3 секунды. Пользователь кликнул — форма открылась. Три секунды — ещё нормально. Двенадцать (4T) — уже больно.
Проведение документа: T = 5 секунд. Зависит от сложности. Для простого расходного ордера — многовато. Для реализации с тысячей строк и контролем остатков — в самый раз.
Формирование отчёта: T = 10 секунд. Отчёты тяжелее операций с данными. Десять секунд для оборотно-сальдовой за квартал — приемлемо.
Запись элемента справочника: T = 2 секунды. Здесь всё должно быть быстро. Если запись номенклатуры занимает дольше двух секунд — ищите проблему в обработчиках событий.
Эти пороги — отправная точка. Через месяц эксплуатации скорректируйте по факту. Если APDEX стабильно 0.98 — можно ужесточить. Если 0.6 — либо пороги нереалистичные, либо система реально тормозит.
Как интерпретировать результаты
APDEX полезен не как абсолютное число, а как тренд. Вчера было 0.92, сегодня 0.87 — что изменилось? Обновили конфигурацию? Добавили пользователей? Выросла база?
Три сценария использования:
Мониторинг деградации. APDEX считается каждый час. Строится график за месяц. Видно: в середине месяца просел — закрытие периода. В конце квартала — ещё сильнее. Это нормальный паттерн. Но если APDEX плавно снижается каждую неделю без видимой причины — база растёт, и запросы деградируют. Пора оптимизировать.
Оценка результата оптимизации. До оптимизации APDEX = 0.72. Переписали запрос в отчёте. После — 0.89. Конкретный, измеримый результат. Можно показать руководству, можно включить в отчёт.
Сравнение между базами. Production: APDEX 0.91. Тестовая с тем же железом: APDEX 0.97. Разница — в данных. На тестовой база маленькая, запросы быстрые. На production — нужна оптимизация индексов.
Важно: APDEX не покажет, где именно проблема. Он покажет, что проблема есть. Для диагностики нужен технологический журнал, замер производительности, анализ планов запросов. APDEX — светофор, а не навигатор.
Типичные ошибки при настройке APDEX
Один порог на всё. T = 5 секунд и для открытия справочника, и для формирования годового отчёта. В результате открытие справочника за 4 секунды считается «нормой», хотя пользователь уже нервничает. А отчёт за 15 секунд — «катастрофой», хотя это вполне приемлемо.
Не исключать фоновые операции. APDEX должен измерять пользовательский опыт. Фоновые задания, регламентные операции, обмены данными — это не то, что чувствует пользователь. Если включить их в APDEX — ночной пересчёт итогов за час утянет метрику вниз, хотя пользователи ничего не заметили.
Не учитывать время суток. В 9:00 все открывают 1С одновременно. APDEX в этот момент просядет — это нормально. Если считать среднее за сутки — пик утра растворится в ночном покое. Лучше считать APDEX отдельно для рабочих часов (9:00-18:00) и отдельно для ночи.
Реагировать на каждое колебание. APDEX упал с 0.93 до 0.89 за один час — это не повод бить тревогу. Может быть, кто-то запустил тяжёлый отчёт. Тревога — когда тренд за неделю стабильно снижается.
С чего начать
Минимальный план на один день:
Утро: включить ЦКК на сервере 1С. Задать пороги для трёх типов операций: открытие форм (T=3с), проведение (T=5с), отчёты (T=10с).
Обед: проверить, что данные собираются. Открыть дашборд ЦКК, убедиться, что APDEX считается.
Вечер: посмотреть первые результаты. Какой APDEX за рабочий день? Если выше 0.85 — система в порядке. Если ниже — есть над чем работать.
Через неделю у вас будет тренд. Через месяц — понимание паттернов нагрузки. Через квартал — основа для аргументированного разговора с руководством о ресурсах и оптимизации. Не «1С тормозит, нужен новый сервер», а «APDEX снизился с 0.91 до 0.78 за три месяца, основная причина — рост таблицы регистра бухгалтерии, нужна оптимизация запросов в закрытии месяца».
