Нагрузочное тестирование 1С:Предприятия 8.3: от стенда до плана исправлений

Производительность 1С тестируют в три слоя одновременно: технологический журнал платформы показывает долгие вызовы и блокировки, счётчики Windows (perfmon) показывают, во что упирается железо, а нагрузочный сценарий (тест Гилева, Тест-центр или свой набор операций) создаёт воспроизводимую нагрузку. Смотреть один слой бессмысленно: «медленно проводится реализация» может оказаться и диском, и ожиданием блокировки, и плохим запросом.

Такой порядок работает при расследовании жалоб «1С тормозит» на клиент-серверных базах 8.3 с MS SQL или PostgreSQL. Для файловой базы применимы тот же журнал, perfmon и замер производительности, без раздела про СУБД.

1. Подготовка стенда перед тестированием производительности

Тест на рабочей базе в рабочее время даёт грязные цифры и мешает людям. Правильнее поднять отдельный стенд.

Что должно совпадать с рабочим контуром

Копию базы делают выгрузкой .dt из Конфигуратора или, быстрее для больших баз, восстановлением резервной копии средствами СУБД с последующей регистрацией базы в кластере.

Настройки ОС, которые искажают результат

• ⚡ Схема электропитания. На Windows Server выставьте «Высокая производительность». В режиме «Сбалансированная» частота процессора плавает, и однопоточные операции 1С заметно проседают.
• 🛡️ Антивирус. Исключите из проверки каталоги баз СУБД, каталог кластера 1С (srvinfo) и папку технологического журнала. Проверка на лету съедает время дисковых операций.
• 🌐 Сеть. Для клиент-серверного варианта замерьте пинг между сервером 1С и СУБД. Если они на разных машинах, задержка выше 1 мс уже ощутима на тысячах мелких запросов.
• 🧹 Регламент СУБД. Перед первым прогоном обновите статистики. Иначе вы померите устаревшую статистику, а не код.

2. Технологический журнал: включить и прочитать

Технологический журнал (ТЖ) — главный инструмент диагностики. Он пишет события платформы с длительностью, контекстом (какая строка кода, какой пользователь) и текстом запроса к СУБД.

Где лежит настройка

ТЖ включается файлом logcfg.xml в каталоге conf установленной платформы, например C:\Program Files\1cv8\conf\logcfg.xml. Платформа перечитывает файл примерно раз в минуту, перезапуск службы не нужен.

Пример настройки под тестирование производительности:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\TechLog\Perf" history="24">
    <event>
      <eq property="name" value="CALL"/>
      <gt property="duration" value="10000"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="10000"/>
    </event>
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <gt property="duration" value="10000"/>
    </event>
    <event>
      <eq property="name" value="TLOCK"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Что здесь происходит:

• history="24" — хранить файлы 24 часа, старые удаляются сами.
• Фильтр duration больше 10000 в условиях logcfg.xml означает дольше одной секунды (единица — десятитысячная доля секунды).
• CALL — серверные вызовы целиком, DBMSSQL и DBPOSTGRS — запросы к MS SQL и PostgreSQL соответственно.
• TLOCK, TTIMEOUT, TDEADLOCK — управляемые блокировки 1С: установка, таймаут ожидания, взаимоблокировка.

Как читать

Файлы лежат по процессам (rphost_<номер>) и часам. Каждая строка начинается с времени и длительности события. Практичный порядок разбора:

1. Отсортируйте события CALL по длительности и возьмите десятку самых долгих.
2. По свойству Context найдите модуль и строку кода, откуда пришёл вызов.
3. Внутри того же интервала времени и того же сеанса найдите DBMSSQL/DBPOSTGRS: какой запрос занял основное время.
4. Если длительность вызова большая, а запросы быстрые — ищите TLOCK с ожиданием или TTIMEOUT: время ушло на ожидание блокировки.

Для больших журналов вручную это не делают: используют скрипты (PowerShell, grep/awk на Linux) или готовые анализаторы ТЖ.

3. Счётчики perfmon: где упирается железо

Журнал отвечает на вопрос «что медленно», perfmon — «почему»: процессор, память, диск или сеть.

Минимальный набор счётчиков

Сохраните список в файл counters.txt:

\Processor(_Total)\% Processor Time
\System\Processor Queue Length
\Memory\Available MBytes
\Memory\Pages/sec
\PhysicalDisk(_Total)\Avg. Disk sec/Read
\PhysicalDisk(_Total)\Avg. Disk sec/Write
\PhysicalDisk(_Total)\Avg. Disk Queue Length
\Network Interface(*)\Bytes Total/sec
\SQLServer:Buffer Manager\Page life expectancy
\SQLServer:SQL Statistics\Batch Requests/sec
\SQLServer:Locks(_Total)\Lock Waits/sec

Последние три — для MS SQL с экземпляром по умолчанию. Запустите сбор раз в 15 секунд в CSV:

typeperf -cf counters.txt -si 15 -o D:\perf\run1.csv -f CSV

Тот же набор можно оформить в графическом perfmon как группу сборщиков данных — удобнее, если сбор нужен регулярно. Отдельно добавьте счётчики процессов rphost, rmngr, ragent и sqlservr: видно, кто именно ест процессор и память.

Ориентиры для интерпретации

Пороги ориентировочные. Важнее динамика: как счётчик меняется в момент, когда журнал фиксирует долгий вызов.

4. Нагрузка по сценариям: тест Гилева, Тест-центр, свои замеры

Счётчики и журнал ничего не покажут, если нагрузки нет. Её создают тремя способами.

Тест Гилева (TPC-1C)

Бесплатная обработка, которая выполняет типовой набор операций записи и чтения и выдаёт условную оценку. Её запускают на пустой файловой и клиент-серверной базе.

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

Ограничение — тест не знает вашей конфигурации. Медленную доработку проведения он не найдёт.

Тест-центр из 1С:КИП

Инструмент из «Корпоративного инструментального пакета» эмулирует многопользовательскую работу: виртуальные пользователи по сценарию одновременно создают и проводят документы. Так ловят то, что одиночный тест не видит: конкуренцию за блокировки и деградацию при 50–200 активных сеансах.

Свой сценарий

Если КИП нет, соберите набор из 5–10 ключевых операций для вашей базы:

1. Проведение типичной реализации на 30–50 строк.
2. Формирование оборотно-сальдовой ведомости за квартал.
3. Закрытие месяца (на копии).
4. Открытие основных списков документов.
5. Обмен с сайтом или с другой базой, если он есть.

Для автоматизации таких сценариев подходит открытый инструмент Vanessa Automation или код на встроенном языке, который в цикле выполняет операции и пишет время в регистр. Главное — каждый прогон с одинаковыми данными и одинаковым числом пользователей.

Замер производительности кода

Для одной медленной операции используйте замер в Конфигураторе: запустите отладку, включите Отладка → Замер производительности, выполните операцию и выключите замер. Откроется таблица строк кода с числом вызовов и долей времени. Обычно 80–90% времени приходится на 2–3 строки, чаще всего с запросом или записью.

5. Блокировки и транзакции на стороне СУБД

Если журнал показывает долгие вызовы при быстрых запросах, время теряется на ожидании. Причин две: управляемые блокировки 1С и блокировки самой СУБД.

Ошибки, по которым узнают проблему

• 🔒 Превышено время ожидания установки блокировки — сеанс не дождался, пока другой отпустит данные. В ТЖ это событие TTIMEOUT.
• 💥 Конфликт блокировок при выполнении транзакции — взаимоблокировка, событие TDEADLOCK. Два сеанса ждут друг друга.

В событиях TLOCK и TTIMEOUT есть свойства с пространством блокировки (имя регистра или таблицы) и номером сеанса-виновника. По номеру находите CALL этого сеанса и его контекст — так виден код, который держит длинную транзакцию.

Что смотреть в MS SQL в момент торможения

SELECT session_id,
       blocking_session_id,
       wait_type,
       wait_time,
       command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Если строк много и blocking_session_id повторяется — один процесс держит всех. Для PostgreSQL аналогичную картину даёт представление pg_stat_activity с полями ожидания и функция pg_blocking_pids().

Типичные причины длинных транзакций

• 🐢 Запросы и обращения к внешним системам внутри транзакции проведения.
• 📦 Проведение документов на сотни строк одной транзакцией в часы пик.
• 🔁 Конфигурация в автоматическом режиме блокировок: СУБД блокирует больше записей, чем нужно. Перевод в управляемый режим — работа программиста, на рабочей базе её не делают «на лету».
• 📊 Регламентные задания (пересчёт итогов, обмены), запущенные в рабочее время.

6. Медленные запросы и индексы

Когда виновник найден — конкретный запрос из DBMSSQL с большой длительностью — дальше работа с текстом запроса и планом.

Признаки плохого запроса 1С

Для MS SQL в logcfg.xml можно добавить элемент <plansql/>, тогда в событиях DBMSSQL появится план выполнения. Включайте его ненадолго: журнал растёт в разы.

Индексы

Индексы в 1С задают в Конфигураторе: у реквизита свойство «Индексировать». Вариант «Индексировать с доп. упорядочиванием» нужен, когда по полю ищут и сразу сортируют. Создавать индексы вручную средствами СУБД нельзя: при следующем обновлении структуры конфигурации их удалит реструктуризация.

Регламент на стороне СУБД так же важен, как код:

• 📈 обновление статистик — ежедневно;
• 🧱 перестроение или реорганизация индексов — раз в неделю, ночью;
• 🗑️ очистка процедурного кэша после обновления статистик (для MS SQL).

7. Интерпретация результатов тестирования производительности 1С

Цифры прогона сводят в оценку, понятную руководству, и в список конкретных задач.

APDEX как общий показатель

Для каждой ключевой операции задают целевое время T, например 3 секунды для проведения реализации. Затем считают:

• довольны — операции не дольше T;
• терпят — от T до 4T;
• недовольны — дольше 4T.

APDEX = (довольны + терпят / 2) / всего операций.

Пример: 100 проведений, 70 уложились в 3 с, 20 — от 3 до 12 с, 10 — дольше. APDEX = (70 + 20 / 2) / 100 = 0,80. Шкала: от 0,94 — отлично, 0,85–0,93 — хорошо, 0,70–0,84 — удовлетворительно, ниже 0,70 — плохо. Значение 0,80 — повод работать.

Связка «симптом → куда копать»

План действий

1. Возьмите три самые долгие операции по APDEX.
2. По каждой найдите узкое место по таблице выше.
3. Исправьте одну причину за раз и повторите прогон того же сценария.
4. Сравните с базовой линией из первого шага.

Меняя несколько вещей сразу, вы не поймёте, что именно помогло.

Частые вопросы