Администрирование · 12 мин
1С: оценка производительности — как использовать инструмент правильно
Как включить и использовать механизм оценки производительности в 1С: замеры времени операций, анализ APDEX, поиск узких мест и типичные ошибки администраторов.
Механизм оценки производительности в 1С — это встроенный инструмент, который автоматически замеряет длительность ключевых операций: проведения документов, выполнения отчётов, обменов данными. Он входит в состав Библиотеки стандартных подсистем (БСП) и присутствует в большинстве типовых конфигураций: «Управление торговлей», «ERP», «Комплексная автоматизация», «Зарплата и управление персоналом» и других.
Смысл инструмента прост: вместо субъективных жалоб пользователей «программа тормозит» вы получаете конкретные цифры — какие операции выполняются дольше нормы, как часто они запускаются и как меняется ситуация со временем. Это первый шаг перед любой оптимизацией: нельзя улучшить то, что не измерено.
Дальше разберём, как включить механизм, настроить замеры, интерпретировать показатель APDEX, найти узкие места и не допустить типичных ошибок, которые приводят к перегрузке базы самим инструментом мониторинга.
Что такое оценка производительности в 1С и зачем она нужна
Механизм построен вокруг понятия «ключевая операция» — это любое действие в системе, длительность которого имеет значение для бизнеса: проведение реализации, закрытие месяца, формирование отчёта по продажам, загрузка данных из обмена. Для каждой операции система фиксирует время начала и окончания выполнения и сохраняет замеры в служебном регистре.
На основе замеров рассчитывается показатель APDEX (Application Performance Index) — общепринятый индекс удовлетворённости производительностью. Операция считается быстрой, если укладывается в целевое время T; допустимой — если выполняется за время до 4T; неприемлемой — если дольше. Итоговый индекс принимает значения от 0 до 1.
Практическая ценность инструмента в трёх сценариях. Во-первых, объективная диагностика жалоб пользователей: вы видите, какая именно операция тормозит и когда это началось. Во-вторых, контроль эффекта от оптимизации: замеры до и после изменения кода или настроек СУБД показывают реальный результат. В-третьих, раннее обнаружение деградации: постепенный рост длительности операций виден задолго до массовых жалоб.
Как включить оценку производительности в типовой конфигурации
В конфигурациях на базе БСП настройка выполняется через интерфейс, без изменения кода. Порядок действий одинаков для большинства типовых решений, отличаются только названия разделов меню.
- 1Откройте раздел «Администрирование» (или «НСИ и администрирование») под пользователем с полными правами.
- 2Перейдите в подраздел «Обслуживание» и найдите пункт «Оценка производительности» (может находиться внутри группы «Общие настройки»).
- 3Установите флаг «Выполнять замеры производительности».
- 4Убедитесь, что регламентное задание «Сбор и обработка замеров производительности» активно и имеет расписание (обычно раз в 1–5 минут).
- 5Проверьте список ключевых операций: типовая поставка уже содержит набор предопределённых операций.
После включения замеры начинают поступать не сразу — нужно дождаться, пока пользователи выполнят отслеживаемые операции, а регламентное задание обработает накопленные данные. Для получения первой статистики обычно достаточно получаса активной работы системы.
Если пункта «Оценка производительности» в меню нет, проверьте две вещи: включена ли функциональная опция в настройках и есть ли у вашей роли право «Администрирование данных оценки производительности». В некоторых конфигурациях раздел доступен только в режиме «Все функции».
Настройка ключевых операций и целевого времени
Ключевая операция настраивается в одноимённом справочнике. Главный параметр — целевое время выполнения в секундах. Именно от него зависит расчёт APDEX: если вы зададите нереалистично малое время, индекс всегда будет низким и перестанет быть информативным; завышенное время скроет реальные проблемы.
Разумный подход — сначала понаблюдать за фактической длительностью операции в течение нескольких дней, а затем установить целевое время чуть выше среднего значения в спокойный период. Например, если проведение документа обычно занимает 1,5–2 секунды, целевое время 3 секунды даст адекватную картину: кратковременные всплески не испортят индекс, а устойчивая деградация будет заметна.
Какие операции отслеживать в первую очередь
Не стоит включать замеры на всё подряд. Начните с операций, которые пользователи выполняют часто и чья длительность критична: проведение основных документов, открытие основных форм списка, ключевые отчёты, обмены с внешними системами. Обычно достаточно 10–30 операций, чтобы покрыть реальную картину нагрузки.
Как читать результаты и находить узкие места
Основной рабочий инструмент — отчёт «Оценка производительности», доступный из того же раздела настроек. Он показывает список ключевых операций с количеством выполнений, средним временем и значением APDEX за выбранный период. Сортировка по индексу сразу выводит наверх самые проблемные операции.
Увидев операцию с низким APDEX, не спешите оптимизировать код. Сначала ответьте на три вопроса. Первый: проблема постоянная или периодическая? Если деградация происходит в одно и то же время суток, ищите конкурирующий процесс — регламентное задание, обмен, резервное копирование СУБД. Второй: у всех пользователей или у конкретного? Локальная проблема чаще связана с сетью, терминальным сервером или клиентским компьютером. Третий: деградация постепенная или резкая? Резкое ухудшение после обновления указывает на регресс в коде или изменение планов запросов.
Как проверить результат
Стабильно выше 0,85 без провалов по времени суток
Регулярные провалы в одни часы или устойчивое снижение неделя к неделе
Соответствует целевому времени или меньше
В 2–4 раза выше целевого даже в спокойные периоды
Растёт умеренно, очистка по расписанию работает
Таблицы замеров раздуваются, база быстро увеличивается в размере
Для глубокого анализа конкретной операции механизма оценки производительности недостаточно — он показывает «что тормозит», но не «почему». Дальше подключаются другие инструменты: технологический журнал с фильтром по длительным запросам, замеры через «Замер производительности» в конфигураторе, анализ планов запросов на стороне СУБД.
Регламентные задания и обслуживание данных замеров
За работу механизма отвечают два регламентных задания. Первое собирает и обрабатывает замеры из буфера в постоянное хранилище. Второе — очищает устаревшие данные. Оба должны быть активны: если отключена очистка, таблицы замеров растут бесконечно.
Проверьте расписание заданий после включения механизма. Слишком частый запуск сбора (каждую минуту при малой активности) создаёт лишнюю нагрузку, слишком редкий (раз в час) приводит к накоплению большого буфера необработанных замеров. Для большинства систем комфортен интервал 1–5 минут.
Отдельно настройте срок хранения замеров. Детальные данные по каждому выполнению быстро теряют ценность; для анализа трендов достаточно агрегированной статистики. Хранение детальных замеров дольше нескольких недель редко оправдано и заметно раздувает базу.
Альтернативные и дополняющие инструменты
Оценка производительности из БСП — не единственный способ измерить скорость работы 1С. В зависимости от задачи имеет смысл комбинировать инструменты.
Сравнение вариантов
Подходит для постоянного мониторинга ключевых операций и контроля APDEX. Ограничение: показывает длительность операции целиком, без детализации внутри.
Незаменим для поиска длительных запросов, блокировок и ошибок. Ограничение: требует настройки logcfg.xml и создаёт большой объём логов, нельзя держать полный сбор постоянно.
Отдельная конфигурация для комплексного мониторинга крупных систем: APDEX, регламентные задания, взаимоблокировки, показатели СУБД. Ограничение: требует отдельного развёртывания и настройки.
Даёт построчную детализацию времени выполнения кода. Подходит для точечной оптимизации конкретной операции, но не для постоянного мониторинга рабочей базы.
Для небольших внедрений обычно достаточно связки «оценка производительности + технологический журнал по требованию». ЦУП оправдан, когда баз несколько, пользователей сотни, и нужен единый центр наблюдения за всем ландшафтом.
Типичные ошибки при использовании механизма
Ещё одна распространённая ситуация: механизм включили, данные копятся, но никто не смотрит отчёт. Оценка производительности работает только как часть процесса — назначьте ответственного, который раз в неделю просматривает операции с APDEX ниже порога и заводит задачи на разбор.
Границы самостоятельной работы и когда привлекать специалистов
Включение механизма, настройка ключевых операций, чтение отчёта и обслуживание регламентных заданий — задачи уровня уверенного администратора 1С, они безопасны и обратимы. Самостоятельно также можно выявить очевидные причины: конкурирующие регламентные задания, переполненные таблицы, отключённую очистку.
Граница проходит там, где начинается оптимизация: изменение запросов и кода конфигурации, настройка индексов СУБД, перестройка планов обслуживания базы данных, анализ взаимоблокировок. Ошибки на этом уровне влияют на целостность данных и доступность системы для всех пользователей. Если узкое место найдено, но требует вмешательства в код или СУБД — привлекайте специалиста по производительности и выполняйте изменения сначала на копии базы.
Что важно запомнить
Включите оценку производительности через «Администрирование — Обслуживание», отслеживайте 10–30 действительно важных операций, задайте реалистичное целевое время и следите за APDEX. Проверяйте работу регламентных заданий сбора и очистки замеров. Механизм показывает, что тормозит; причину ищите технологическим журналом и инструментами СУБД, а глубокую оптимизацию доверяйте специалистам.
Частые вопросы
Оценка производительности замедляет работу базы?
Сам по себе замер добавляет к операции доли миллисекунды — это незаметно. Нагрузку создают записи замеров и работа регламентных заданий. Если отслеживать умеренное число операций и не отключать очистку устаревших данных, влияние на производительность пренебрежимо мало.
Почему в отчёте пусто, хотя механизм включён?
Чаще всего не работает регламентное задание сбора замеров: проверьте, что оно активно, не завершилось с ошибкой и что расписание задано. Вторая причина — пользователи просто не выполняли отслеживаемые операции за выбранный период отчёта. Третья — нет прав на данные оценки производительности у текущего пользователя.
Можно ли добавить замер своей операции в доработанном коде?
Да, в БСП предусмотрен программный интерфейс: в начале фрагмента кода вызывается начало замера с указанием имени ключевой операции, в конце — фиксация окончания. Операцию нужно предварительно создать в справочнике ключевых операций. Детали смотрите в документации к вашей версии БСП, так как имена процедур модуля «ОценкаПроизводительности» могут отличаться.
Какое значение APDEX считать нормальным?
Общепринятой считается граница 0,85: выше — пользователи в основном довольны скоростью. Диапазон 0,5–0,85 означает, что часть выполнений заметно медленнее целевого времени, и стоит разобраться в причинах. Ниже 0,5 — большинство операций выполняются медленно, требуется планомерная оптимизация. Но ориентируйтесь и на динамику: падение индекса с 0,95 до 0,87 уже сигнал, даже если формально значение «хорошее».
Работает ли механизм в файловой базе?
Работает, но с оговорками. В файловом варианте регламентные задания выполняются в сеансе пользователя, запустившего их обработку, поэтому сбор замеров зависит от того, запущен ли такой сеанс. Кроме того, в файловых базах особенно важно ограничивать объём хранимых замеров — рост базы напрямую влияет на скорость её работы.
Чем оценка производительности отличается от ЦУП?
Оценка производительности — встроенный механизм БСП, замеряющий длительность операций внутри одной базы. Центр управления производительностью — отдельная конфигурация, которая собирает показатели с нескольких баз одновременно: APDEX, длительные запросы, блокировки, регламентные задания, метрики СУБД. Для одной небольшой базы достаточно встроенного механизма; ЦУП оправдан при нескольких крупных системах.