Высоконагруженные системы требуют аккуратности в случае с установкой интеграционных решений в виде расширений. Такие расширения, как правило, под капотом содержат план обмена и подписки на события для регистрации выгружаемых данных, которые потенциально могут уменьшить производительность. Снизить риски поможет несложная процедура нагрузочного тестирования.
Разберём этот вариант на конкретном примере. Мы будем тестировать информационную базу конфигурации «1С:Управление торговлей 11.5» (далее УТ).
Дано:
- несколько расширений с множеством доработок,
- более миллиона клиентов,
- примерно 1,5 тысячи заказов ежедневно,
- продуктовая система работает в режиме 24/7,
- в пике до 500 активных пользователей.
Для чего нужен экстрактор данных 1С
На странице продукта даётся следующее определение экстрактора:
Экстрактор данных 1С — это инструмент, который полностью автоматизирует получение данных из программы. Больше не нужно привлекать программиста для настройки обмена между 1С и внешним хранилищем: вы настраиваете инструмент один раз, и базы регулярно обновляются. Полученные данные можно использовать для анализа в BI-системах: Yandex Datalens, Power BI, Visiology, Loginom и других.
Модуль устанавливается в качестве расширения (или как встройка в конфигурацию 1С), работает с любыми конфигурациями 1С на платформах 1С 8.2 и 8.3, далее в нём настраивается регистрация и последующая выгрузка любых объектов из базы 1С по расписанию.
Подготовка к тестированию
За основу мы взяли конфигурацию 1С «Тест-центр» из корпоративного инструментального пакета, объединили её с конфигурацией УТ. Обработки для выполнения нагрузочного тестирования взяли из демо конфигурации 1С «ERP + тест-центр», адаптировав под УТ.
Составили сценарий тестирования, в который включили основные объекты, задействованные в рабочем процессе.
Развернули две идентичные копии базы. В одну из них установили интеграционный модуль Экстрактор 1С, и настроили регистрацию изменений по регистрам накопления:
- «Заказ клиента»,
- «Заказ поставщику»,
- «Выручка и себестоимость»,
- «Прочие доходы»,
- «Прочие расходы»,
- «Расчёты с клиентами»,
- «Движение денежных средств»,
и справочникам:
- «Номенклатура»,
- «Контрагенты»,
- «Договоры контрагентов».
Экстрактор данных 1С в BI был настроен на риалтайм-отслеживание изменений в указанных регистрах накопления и справочниках (используется механизм «Подписки на события»). Никакие оптимизации обработчиков подписок на изменения не делались, все настройки были из «коробки».
Тестирование
Чтобы исключить внешние факторы, решили провести три теста с экстрактором 1С и три без него.
Само тестирование проходит в автоматическом режиме. От оператора требуется только указать сценарий тестирования в подсистеме «Тест-центр» и нажать «Выполнить». Система сама запускает указанное в сценарии количество клиентских сеансов (виртуальных рабочих мест), выполняет операции, сохраняет замеры и завершает работу клиентов. На выходе мы получаем отчёт, который можно сохранить в Excel для дальнейшего анализа.
Колонки в отчёте:
- Ключевая операция — текстовое представление выполняемой операции.
- Приоритет и Целевое время — параметры для расчёта показателей по методике APDEX, в данном случае мы её не использовали.
- Количество замеров — сколько раз выполнялась операция в данном тесте.
- APDEX — оценка по соответствующей методике.
- Средняя, минимальная и максимальная продолжительность — время выполнения теста в секундах.
- Дисперсия и стандартное отклонение — меры отклонений результатов замеров от среднего значения.
Анализ результатов
Мы получили 6 excel-файлов с показателями, по 3 замера без установленного расширения и по три с расширением. Из этих файлов для каждого теста мы взяли одну колонку — среднее время выполнения замера — и сделали по ней раскраску. Красным выделены максимальные (плохие) значения, а зелёным — минимальные (хорошие).
Визуально особой закономерности не видно. Какие-то тесты прошли быстрее без расширения, какие-то с расширением, т. е. в среднем всё хорошо — деградации производительности с использованием расширения «Экстрактор 1С» не произошло.
Поскольку цель исследования — сравнить производительность с расширением и без, попробуем выявить проблемные операции. Для этого рассчитаем разницу средних значений результатов без расширения и с установленным расширением.
Здесь стоит оговориться, что в общем случае брать среднее арифметическое от уже усреднённого показателя будет ошибкой. Но не в нашем случае, т. к. у нас постоянный размер выборки.
Поясню на примере
Для теста «Тест центр. документ. заказ клиента. проведение. закрыт» мы провели три теста, внутри каждого провели по три замера и получили средние результаты тестов:
1.676
0.215
0.216
Суммарное время выполнения замеров:
1.676 * 3 + 0.215 * 3+0.216 * 3 = 6,321 сек.
Общее количество замеров:
3*3 = 9
Среднее значение замера:
6,321 / 9 = 0,702 сек., что равно (1.676 + 0.215 + 0.216) / 3 = 0,702 сек.
То есть при постоянном размере выборки она сокращается из числителя и знаменателя, и усреднение средних значений становится допустимым.
Итак, упорядочиваем таблицу по разнице средних значений и выводим топ 10 тестов, производительность которых ухудшилась с установкой расширения.
В первых 8 операциях из 178 проверенных присутствует заметное снижение производительности как в абсолютном значении, так и в относительном. Все проблемные операции связаны с тремя видами документов: Заказ клиента, ПКО, РКО.
Если посмотреть нижнюю часть таблицы, можно увидеть множество операций, время выполнения которых сократилось.
Очевидно, это объясняется влиянием внешних (по отношению к конфигурации и расширению) факторов, которые вносят свою погрешность в измерения.
Подводим итоги
По результатам тестирования заказчик получил рекомендации:
- Установить расширение. Всё-таки в нашем случае 95% операций прошли без изменения производительности, только 5% показали ухудшение. Любой дополнительный функционал требует ресурсов, это нормально.
- После установки проконтролировать изменение APDEX по выявленным проблемным операциям. Если появится ухудшение показателей, провести локальную оптимизацию.
Заключение
Как быть, если требуется расширение, но вы опасаетесь, что оно повлияет на производительность? Мы рекомендуем использовать нагрузочное тестирование.
Разумеется, нагрузочное тестирование не является некой волшебной таблеткой. Как видим, результаты могут быть противоречивыми (часть тестов с допмодулем выполнилась быстрее), и искусственная нагрузка может недостаточно точно повторять поведение продуктовой системы. Тем не менее проведение нагрузочного тестирования позволяет выявить грубые проблемы и подсветить операции, которые требуют внимания после установки модуля.
В эксперименте уложились в 50 человеко-часов. Это совсем немного, если учесть, что большая часть времени ушла на подготовку тестов, которые планируется использовать для периодического тестирования новых изменений в системе.
