Высоконагруженные системы требуют аккуратности в случае с установкой интеграционных решений в виде расширений. Такие расширения, как правило, под капотом содержат план обмена и подписки на события для регистрации выгружаемых данных, которые потенциально могут уменьшить производительность. Снизить риски поможет несложная процедура нагрузочного тестирования.
Разберём этот вариант на конкретном примере. Мы будем тестировать информационную базу конфигурации «1С:Управление торговлей 11.5» (далее УТ).
Дано:
На сайте производителя даётся следующее определение экстрактора:
Экстрактор данных 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 для дальнейшего анализа.
Колонки в отчёте:
Мы получили 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 проверенных присутствует заметное снижение производительности как в абсолютном значении, так и в относительном. Все проблемные операции связаны с тремя видами документов: Заказ клиента, ПКО, РКО.
Если посмотреть нижнюю часть таблицы, можно увидеть множество операций, время выполнения которых сократилось.
Очевидно, это объясняется влиянием внешних (по отношению к конфигурации и расширению) факторов, которые вносят свою погрешность в измерения.
По результатам тестирования заказчик получил рекомендации:
Как быть, если требуется расширение, но вы опасаетесь, что оно повлияет на производительность? Мы рекомендуем использовать нагрузочное тестирование.
Разумеется, нагрузочное тестирование не является некой волшебной таблеткой. Как видим, результаты могут быть противоречивыми (часть тестов с допмодулем выполнилась быстрее), и искусственная нагрузка может недостаточно точно повторять поведение продуктовой системы. Тем не менее проведение нагрузочного тестирования позволяет выявить грубые проблемы и подсветить операции, которые требуют внимания после установки модуля.
В эксперименте уложились в 50 человеко-часов. Это совсем немного, если учесть, что большая часть времени ушла на подготовку тестов, которые планируется использовать для периодического тестирования новых изменений в системе.
Похожие статьи
