Как измерить время отклика системы и сымитировать работу 30 пользователей в 1С?

← На главную

Разработка собственной конфигурации или доработка существующего решения всегда завершается вопросом: насколько быстро работает система и как она поведет себя при одновременной работе нескольких десятков сотрудников? При выполнении стандартных действий — проведении документов, записи элементов справочников или формировании отчетов — важно зафиксировать реальное время ожидания пользователя.

Разберем основные методы измерения производительности, выясним, почему синтетических тестов производительности процессора недостаточно, и проанализируем практические способы эмуляции нагрузки от 30 одновременных пользователей.

Почему стандартного теста производительности недостаточно

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

Специфика метаданных: Синтетика не учитывает логику проведения ваших документов, количество регистров накопления и сведений, наличие избыточных индексов и состав реквизитов.
Клиентский контекст: Тест не измеряет время формирования интерфейса, работу динамических списков и сетевую задержку между рабочим местом и сервером.
Конкуренция за данные: Реальные пользователи нередко блокируют одинаковые диапазоны данных (например, остатки на складе), что приводит к ожиданиям на блокировках, которые синтетические тесты не воспроизводят.

Методология APDEX и подсистема «Оценка производительности»

Рассмотрим стандартный подход к оценке времени отклика, принятый на платформе «1С:Предприятие». Если конфигурация разработана с использованием Библиотеки стандартных подсистем (БСП), наиболее правильным инструментом выступает подсистема Оценка производительности, основанная на стандарте APDEX (Application Performance Index).

Принцип работы методики заключается в определении целевого времени выполнения каждой операции и последующем сопоставлении с фактическими замерами:

Определим список ключевых операций: например, ПроведениеДокумента_ЗаказПокупателя, ФормированиеОтчета_ОстаткиТоваров, ОткрытиеФормы_Номенклатура.
Зададим целевое время в секундах, за которое операция должна выполняться в идеале (например, 2 секунды на проведение).
Зафиксируем начало и конец операции непосредственно в коде при помощи вызовов подсистемы. Замер стартует при нажатии кнопки пользователем на клиенте и завершается при возврате управления форме, фиксируя полное время цикла.
Соберем статистику в разрезе пользователей и определим интегральный балл качества работы системы от 0 до 1.

Имитация нагрузки через фоновые задания: плюсы и ограничения

Один из самых простых способов проверить устойчивость базы — запуск пула фоновых заданий, как было предложено участниками обсуждения. Разберем, как реализовать такой механизм и с какими ограничениями придется столкнуться.

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


// Процедура запуска пула потоков нагрузки
Процедура ЗапуститьНагрузкуНаСервере()
    КоличествоПотоков = 30;
    МассивЗаданий = Новый Массив;
    
    Для Индекс = 1 По КоличествоПотоков Цикл
        ПараметрыЗадания = Новый Массив;
        ПараметрыЗадания.Добавить(Индекс);
        
        Задание = ФоновыеЗадания.Выполнить("НагрузочноеТестированиеСервер.ВыполнитьПакетОпераций", 
            ПараметрыЗадания, 
            Строка(Новый УникальныйИдентификатор), 
            "Тестовый поток №" + Строка(Индекс));
            
        МассивЗаданий.Добавить(Задание);
    КонецЦикла;
КонецПроцедуры

// Процедура внутри общего модуля, выполняющая полезную нагрузку
Процедура ВыполнитьПакетОпераций(НомерПотока) Экспорт
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    
    // Выполняем стандартные операции: выборка, запись, проведение
    Для Шаг = 1 По 10 Цикл
        ДокументОбъект = ПолучитьТестовыйДокумент(НомерПотока, Шаг);
        ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
    КонецЦикла;
    
    ВремяОкончания = ТекущаяУниверсальнаяДатаВМиллисекундах();
    Длительность = ВремяОкончания - ВремяНачала;
    
    ЗаписьЖурналаРегистрации("НагрузочноеТестирование", 
        УровеньЖурналаРегистрации.Информация, 
        , 
        , 
        "Поток " + Строка(НомерПотока) + " завершен за " + Строка(Длительность) + " мс.");
КонецПроцедуры

Проанализируем ограничения этого подхода:

Исключительно серверное выполнение: Фоновые задания не взаимодействуют с клиентской частью. Они не отрисовывают формы, не запрашивают данные через контекстные серверные вызовы управляемых форм и не показывают время отклика интерфейса.
Отсутствие времени на размышление: Фоновое задание выполняет код без пауз, создавая плотный поток транзакций. Реальные пользователи тратят секунды на ввод реквизитов и чтение информации с экрана. Отсутствие пауз может спровоцировать ложные взаимоблокировки, которых не возникнет при реальной эксплуатации.
Эффект кэширования: При одновременном старте однотипных заданий данные быстро попадают в кэш СУБД, что может дать ложноположительную картину высокой скорости чтения.

Использование специализированных инструментов тестирования

Для приближения условий теста к реальной работе 30 пользователей целесообразно использовать штатные средства многопользовательского нагрузочного тестирования.

Тест-Центр: Специализированный программный продукт, позволяющий моделировать одновременную работу сотен виртуальных пользователей. Сценарии описываются на встроенном языке или оформляются через расширение. Тест-Центр самостоятельно управляет запуском сеансов, эмулирует паузы между действиями пользователей и собирает детальные метрики производительности.
Механизм автоматизированного тестирования платформы: Платформа «1С:Предприятие 8.3» поддерживает запуск тонких клиентов в режимах /TestManager (менеджер тестирования) и /TestClient (клиент тестирования). С помощью тестовых сценариев можно автоматизировать реальный интерфейс: открывать формы, заполнять табличные части и нажимать кнопки. Для создания нагрузки 30 сеансов запускаются на тестовых машинах или терминальных серверах под разными учетными записями.
Нагрузка через HTTP-сервисы: Если конфигурация спроектирована с разделением логики и предоставляет программные API, операции проведения и записи можно вызвать через методы HTTP-сервисов. В этом случае подача 30 параллельных потоков осуществляется через внешние утилиты нагрузочного тестирования, что позволяет получать перцентили времени отклика сервера без необходимости разворачивать 30 графических клиентов.

Анализ проблем производительности через Технологический журнал

Когда замеры покажут неприемлемое время отклика при параллельной работе, необходимо локализовать узкое место. Для этого используют Технологический журнал платформы со сбором следующих событий:

Событие CALL с фильтром по длительности позволяет отследить контекстные серверные вызовы, выполняющиеся дольше допустимого порога.
События DBMSSQL или DBPOSTGRS выявляют тяжелые запросы к СУБД при проведении документов и формировании отчетов.
События TLOCK, TTIMEOUT и TDEADLOCK фиксируют конфликты блокировок между сеансами, возникающие при конкурентной записи в одни и те же таблицы.

Комбинация методики APDEX для замера времени ключевых операций и симуляции сеансов пользователей через автоматизированные сценарии дает наиболее объективную картину готовности системы к промышленной нагрузке.