Нагрузочный тест 1С перед запуском: от замысла до отчёта
Содержание
Нагрузочное тестирование 1С нужно провести, когда в базу собираются посадить заметно больше пользователей, чем работало раньше, или когда меняют сервер, СУБД, конфигурацию. Порядок такой: собрать копию боевой базы на стенде, записать типовые сценарии работы, прогнать их с растущим числом виртуальных пользователей и сравнить время операций с принятыми порогами. Всё остальное — детали, и в деталях обычно всё и ломается.
Типичная история. Бухгалтерия на 15 человек переезжает на новый сервер, к ним добавляют склад и отдел продаж, всего 60 пользователей. В тесте на двух людях всё летает. В понедельник в 9 утра все закрывают смены, проводят реализации, и проведение документа вместо 2 секунд занимает минуту. Нагрузочный тест нужен, чтобы увидеть этот понедельник заранее.
Для чего проводят нагрузочное тестирование и когда оно оправдано
Тест отвечает на четыре вопроса:
- 👥 Сколько пользователей выдержит система при приемлемой скорости работы.
- 🔍 Где узкое место: процессор сервера 1С, память, диски, сеть, блокировки или запросы к СУБД.
- 📈 Как система деградирует: плавно или обрывом, когда после некоторого порога время отклика растёт втрое.
- ✅ Помогла ли оптимизация: прогон до и после правки даёт сравнимые цифры.
Не всегда тест нужен. Для базы на 5 пользователей он избыточен: хватит замера производительности и просмотра технологического журнала. Зато в этих случаях без него рискованно:
| Ситуация | Что проверяем |
|---|---|
| Рост числа пользователей в 2 раза и больше | Предельное число сеансов, память сервера 1С |
| Переезд на другой сервер или в облако | Сравнение с текущей скоростью, диски и сеть |
| Смена СУБД (например, с файловой на клиент-серверную) | Время ключевых операций до и после |
| Обновление платформы или конфигурации с доработками | Регрессия в проведении и отчётах |
| Запуск пиковых процессов: закрытие месяца, массовые начисления | Блокировки и время фонового выполнения |
Если у вас пока нет живых пользователей (новая база), нагрузку описывают по плану: сколько человек, какие операции в час, когда пик. Цифры берут у руководителей подразделений, а не «с потолка».
Подготовка стенда, данных и критериев успеха
Стенд должен быть похож на боевой. Тест на слабой виртуалке с пустой базой покажет красивые цифры, которые в работе не повторятся.
Железо и настройки
Что воспроизвести максимально точно:
- Версию платформы 1С и версию конфигурации.
- Тип и версию СУБД, параметры сервера СУБД.
- Число ядер, объём памяти, тип дисков (SSD или HDD), схему хранения.
- Режим работы: клиент-серверный вариант, число рабочих серверов, способ подключения пользователей (тонкий клиент, веб-клиент, терминальный сервер ).
Если полной копии железа нет, тест можно проводить на уменьшенном стенде, но выводы тогда применяют осторожно: масштабирование почти никогда не линейно.
Данные
Берут копию рабочей базы за последние месяцы. На пустой базе не проявятся ни рост таблиц регистров, ни план запросов, который меняется от объёма данных. Перед тестом:
- ⚠️ Обезличьте или закройте доступ к тестовой копии: в ней реальные контрагенты, зарплата, банковские реквизиты.
- Отключите на копии регламентные задания обмена, рассылки и отправку писем, иначе тест начнёт слать реальные документы контрагентам и в банк.
- Обновите статистику СУБД и выполните типовое обслуживание, как на боевой базе.
Критерии успеха
Пороги договариваются до теста, не после. Пример для учётной системы:
| Тип операции | Приемлемое время |
|---|---|
| Открытие списка документов | до 2–3 секунд |
| Проведение обычного документа | до 3–5 секунд |
| Формирование типового отчёта за месяц | до 30–60 секунд |
| Закрытие месяца | в рамках заранее согласованного окна |
Эти числа ориентировочные. Подставьте свои, исходя из того, что терпят ваши пользователи.
Какие инструменты выбрать для нагрузочного тестирования
Единого «правильного» средства нет, всё зависит от клиента, бюджета и того, что нужно измерить.
Средства от 1С
В составе корпоративного инструментального пакета есть решения для автоматизированного тестирования, включая сценарное и нагрузочное, а также отдельный инструмент для контроля производительности в промышленной эксплуатации. Их преимущество в том, что они «понимают» объекты 1С: записывают действия на уровне форм и команд, а не координат на экране. Стоят отдельных денег, подробности лицензирования уточняйте у партнёра.
Универсальные средства
Для веб-клиента применимы HTTP-генераторы нагрузки вроде JMeter или Gatling. Но здесь есть подвох: интерфейс веб-клиента 1С передаёт состояние форм через служебные запросы, и скрипт приходится аккуратно собирать из записанного трафика, подставляя динамические значения. На это уходят дни.
Собственные скрипты и обработки
Для точечных задач проще написать внешнюю обработку , которая в цикле создаёт и проводит документы под несколькими пользователями. Это не полноценная имитация работы клиента, но для проверки блокировок и скорости проведения подходит.
Что взять
| Подход | Плюсы | Минусы |
|---|---|---|
| Инструменты 1С | Работают на уровне объектов 1С, меньше ручной настройки | Платные, нужно освоить |
| JMeter и аналоги | Бесплатны, гибки | Тяжёлая сборка скриптов под веб-клиент |
| Свои обработки | Дёшево, под конкретный процесс | Не воспроизводят нагрузку клиентского интерфейса |
| Замер «вживую» | Реальные пользователи, реальные операции | Нет контроля и повторяемости |
Для небольшой компании разумная связка: свои обработки для проведения плюс технологический журнал и мониторинг сервера.
Как составить сценарии тестирования
Сценарий — последовательность действий одного типового пользователя. Нагрузка составляется из нескольких сценариев в нужных пропорциях.
Шаг 1. Выделите роли и операции
Возьмите журнал регистрации или статистику документов за пиковый месяц и посмотрите, что на самом деле делают люди:
- Менеджеры по продажам создают заказы и реализации.
- Кладовщики оформляют поступления и перемещения.
- Бухгалтеры вводят первичку и формируют отчёты.
- Руководители открывают оперативные отчёты.
Шаг 2. Задайте пропорции
Допустим, в пик работают 60 человек: 30 менеджеров, 10 кладовщиков, 15 бухгалтеров и 5 руководителей. Сценарии запускаются в тех же пропорциях: 30 / 10 / 15 / 5, а не «по 15 каждого».
Шаг 3. Опишите сценарий по шагам
Хороший сценарий состоит из операций, которые можно измерить отдельно:
- Открыть форму списка документов.
- Создать новый документ, заполнить из справочников.
- Провести и закрыть.
- Открыть отчёт с отбором.
Каждый шаг получает свой замер, иначе после теста непонятно, что тормозило.
Шаг 4. Добавьте «думающее время»
Реальный человек не жмёт кнопки подряд. Между действиями ставят паузы 5–30 секунд, иначе 60 виртуальных пользователей создадут нагрузку, как для 300 реальных, и результат будет мрачнее действительности.
Шаг 5. Разнообразьте данные
Если все виртуальные пользователи проводят документ на один и тот же товар, вы получите искусственные блокировки. Подставляйте разные номенклатуру, склады, контрагентов, как в жизни.
Отдельно заложите фоновую нагрузку: обмены, регламентные задания, формирование тяжёлых отчётов. Боевая база страдает не только от пользователей.
Запуск тестов и наблюдение за системой
Сам прогон — это не «нажать и ждать». Нагрузку наращивают ступенями, например 10, 20, 40, 60, 80 пользователей, и на каждой ступени держат 15–30 минут. Так видно, на каком числе начинается деградация.
Что мерять во время прогона
На стороне серверов:
- 💻 загрузку процессоров и очередь запросов;
- 🧠 потребление памяти процессами сервера 1С и СУБД;
- 💾 задержки дисков (время на чтение и запись, а не только процент загрузки);
- 🌐 сеть между клиентами, сервером 1С и СУБД.
На стороне 1С:
- время выполнения операций из сценариев;
- число сеансов и соединений, длину очередей на сервере приложений;
- блокировки и ожидания: события
TLOCK,TTIMEOUT,TDEADLOCKв технологическом журнале.
Технологический журнал
Журнал настраивается файлом logconfig.xml в каталоге конфигурации сервера. Для нагрузочного теста обычно собирают события о запросах к СУБД (DBMSSQL для MS SQL или DBPOSTGRS для PostgreSQL), вызовах сервера (CALL) и блокировках. Ограничьте журнал по длительности (например, только события дольше 1 секунды) и по объёму, иначе он забьёт диск.
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\techlog" history="4">
<event>
<eq property="name" value="TDEADLOCK"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
</event>
<event>
<eq property="name" value="CALL"/>
<ge property="duration" value="1000000"/>
</event>
<property name="all"/>
</log>
</config>
Длительность в техжурнале указывается в микросекундах, значение 1000000 равно одной секунде. Путь C:\techlog подставьте свой.
На стороне СУБД
Для PostgreSQL удобно расширение pg_stat_statements, которое показывает самые дорогие запросы по суммарному времени. Для MS SQL Server используйте динамические представления статистики запросов и ожиданий.
Не запускайте тест на боевом сервере в рабочее время. Нагрузочный прогон специально доводит систему до предела, и пользователи это почувствуют.
Анализ результатов и оптимизация узких мест
После прогона у вас три набора данных: время операций по ступеням нагрузки, метрики серверов, журнал. Сводите их в одну картину по времени.
Как читать картину
Ищите точку излома: число пользователей, при котором время отклика пошло вверх быстрее, чем число пользователей. Что происходило на серверах в этот момент?
| Что видно | Вероятная причина | Что делать |
|---|---|---|
| Процессор сервера 1С почти 100% | Не хватает ядер или тяжёлый серверный код | Профилирование кода, добавление рабочих процессов или серверов |
| Процессор свободен, но операции долгие | Ожидания блокировок | Разбор TLOCK/TTIMEOUT, пересмотр транзакций |
| Высокие задержки дисков СУБД | Медленное хранилище, перегруженные журналы транзакций | Диски быстрее, разнесение данных и журналов |
| Память упирается в предел | Утечка сеансов, мало ОЗУ | Лимиты памяти процессов, больше ОЗУ |
| Один запрос съедает половину времени | Неудачный план, нет индекса | Оптимизация запроса, обслуживание статистики |
| Время растёт при нормальных метриках | Сеть или клиентская часть | Проверка каналов, режима подключения |
Типовой порядок оптимизации
- Начинайте с самых дорогих по суммарному времени запросов и операций, а не с самых медленных единичных.
- Меняйте что-то одно и повторяйте тот же прогон. Если правок две, вы не узнаете, какая сработала.
- Блокировки лечите уменьшением транзакций: меньше объектов в одной транзакции, управляемые блокировки данных, правильный порядок обращения к таблицам.
- Оборудование докупайте последним. Часто один исправленный запрос даёт больше, чем новый сервер.
Что записать в отчёт
- Конфигурация стенда и отличия от боевого.
- Профиль нагрузки: сценарии, пропорции, длительность ступеней.
- Таблица времени операций по ступеням.
- Найденные узкие места и принятые меры.
- Вывод: сколько пользователей система выдерживает в рамках порогов и что делать при росте.
Типичные ошибки при нагрузочном тестировании
Ошибки повторяются из проекта в проект. Пять самых дорогих:
- ❌ Тест на пустой или маленькой базе. Цифры радуют, а на боевом объёме ломаются.
- ❌ Нет «думающего времени». Нагрузка получается нереалистично жёсткой, и вы лечите проблему, которой нет.
- ❌ Один тип пользователя. Работает реальная смесь ролей, а блокировки возникают как раз на их пересечении.
- ❌ Журнал без ограничений. Диск стенда заполнился на середине прогона, результат потерян.
- ❌ Один прогон вместо серии. Разовый замер может попасть на случайный пик (бэкап, антивирус). Повторите 2–3 раза и берите медиану.
Ещё одно: сравнение «до» и «после» на разном составе данных. Если между прогонами база изменилась, сравнивайте только после восстановления из одной и той же копии.
Если нагрузочный тест не показал причину
Бывает, что стенд ведёт себя прилично, а в бою всё равно тормозит. Тогда:
- Проверьте, нет ли в боевой среде того, чего нет на стенде: антивирус, резервное копирование в рабочее время, соседние виртуальные машины на том же хосте.
- Включите замер производительности и сбор технологического журнала в самой рабочей базе на короткое время пика (с лимитом объёма).
- Сравните реальный профиль нагрузки с вашим сценарием: возможно, пользователи делают то, что вы не учли, например выгружают огромные отчёты в Excel.
- Прогоните тест поменьше, но на самой проблемной операции, и разберите её по шагам.