Программы 1С

Нагрузочное тестирование систем 1С

Name: Нагрузочное тестирование систем 1С
SKU: 2105942

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

Арт.: 2105942

Что такое нагрузочное тестирование и зачем оно нужно?

Проверка на надежность и бесперебойность работы

Проверка готовности 1С-решений к работе в условиях нагрузок без значительного снижения скорости и качества обслуживания

Проверка на соответствие системы потребностям компании

Гарантия соответствия заявленным технологическим требованиям в процессе эксплуатации информационной системы

Обнаружение возможных проблем

Выявление проблем, связанных с производительностью и нагрузкой на систему

Нагрузочное тестирование — это процесс анализа и оценки производительности и надежности информационных систем 1С.

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

Другие решения

Когда нужно проводить нагрузочное тестирование?

Из чего состоит классическое нагрузочное тестирование?

Согласно классическому подходу, проект по нагрузочному тестированию всегда начинается с разработки моделей нагрузки, в ходе которой:

Определяются операции, которые нужно включить в тест

Выбирается интенсивность выполнения операций

Устанавливается целевое количество пользователей

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

Минусы классического подхода к нагрузочному тесту

Временные затраты

Этап разработки моделей нагрузки может занимать до 50% времени всех работ по нагрузочному тестированию

Трудовые затраты

Большие трудозатраты по разработке скриптов на каждую тестируемую операцию. Изначально приходится закладывать большие сроки

Нет корреляции с реальной нагрузкой

Бизнес-аналитики не всегда понимают требования, которые нужно предъявлять к системе под нагрузкой

Нереалистичные данные

Низкая вариативность данных заполнения из-за ограниченного набора данных при нагрузочном тестировании

Что мы предлагаем?

Для максимальной автоматизации тестирования и решения этих проблем мы разработали концепцию решения

Эксплуатируемая база 1С

Подсистема Тест-центр в 1С:КИП

Сбор данных

Анализируем информацию из большого количества источников (ТЖ, ЖР, замеры времени, данные СУБД, история данных и отчетов)

Генерация сценариев

Автоматизированная генерация сценария нагрузочного тестирования по заданным параметрам

Запуск тестов

Автоматизированный итерационный запуск тестов по заданным параметрам

Анализ результатов

Визуализация сравнительного анализа полученных результатов

Оставляйте заявку на расчет стоимости по нагрузочному тестированию и получайте бесплатную консультацию эксперта!

Рассмотрим каждый из перечисленных этапов подробнее

1. Сбор данных

Отбираем только наиболее частые и ресурсоемкие операции - длительные операции, операции с большой нагрузкой и потреблением памяти, наиболее частые операции и т.д.
Для получения параметров всех выполняемых системой операций, мы используем технологический журнал (ТЖ), замеры времени из подсистемы оценки производительности APDEX и данные СУБД
Парсеры разбирают ТЖ и записывают данные в базу ClickHouse, откуда мы получаем топ операций и параметры: целевое расчетное время, частоту выполнения, частых пользователей операций и т.д.
Для получения данных для теста мы используем платформенную историю данных - делаем бэкап продуктивной базы, включаем историю данных, ждем накопления объема, выключаем историю данных и выгружаем действия из истории данных в файлы JSON
Второй источник данных – это история параметров формирования отчетов. Мы сохраняем настройки формирования пользовательских отчетов, записывая эти настройки в регистр сведений
По итогу, мы можем автоматически генерировать разные виды операций - проведение документов, формирование отчетов, запись элементов справочников, открытие форм, выполнение команд и т.д.

2. Генерация сценариев

Задавая параметры теста, мы определяем длительность сценария, количество пользователей, можем влиять на интенсивность ввода операций
На этапе создания модели нагрузочного теста у нас происходит распределение подобранных ранее операций по пользователям и по клиентским машинам, плюс подбираются данные для заполнения
Далее мы создаем недостающие ссылки для выполнения операций и доводим базу до состояния, когда в ней есть все необходимые данные для выполнения операций теста
Далее мы записываем наш детальный план в регистр сведений, что обеспечивает нам полную повторяемость при разных запусках
И выполняем настройку пользователей, если в базе используется сложный RLS
Результат всего подготовительного этапа – это СУБД-шный бэкап, который мы будем разворачивать перед каждым запуском

17_20_18_00_Доклад_Величаева_Литвинов_1_1_page-0011.jpg

3. Автоматический итерационный запуск тестов

Когда нам нужно большое количество запусков с разными параметрами инфраструктуры – для этого предусмотрен автоматический итерационный запуск
Начинается все с автоматического развертывания инфраструктуры по заданным параметрам
После подготовки инфраструктуры восстанавливаем бэкап, который мы сделали на подготовительном этапе
Запускаем тест скриптом. На входе мы передаем настроечный файл - какой сценарий запускать, на каких машинах, с каким тайм-аутом и настройками и формат результата – т.е. как записывать
Выполняется тест и получаем результаты в базу ClickHouse: протокол тестирования, замеры производительности – замеры времени и метрики операционной системы
Очищаем. И переходим на новый круг с новыми параметрами развертывания инфраструктуры

17_20_18_00_Доклад_Величаева_Литвинов_1_1_page-0012.jpg

4. Анализ результатов

Для удобства визуализации мы используем дашборды Redash
Основные показатели для сравнения – это APDEX и метрики операционной системы. По APDEX можем смотреть: сводные значения, значения в разрезе операций, группировать по типу операций (сравнить, как менялся APDEX именно для проведения документов или для формирования отчетов)
Результат фиксируем в отчете о проведении нагрузочного тестирования

Преимущества нового подхода

Сокращение сроков

За счет автоматизации самых длительных этапов сокращаются сроки подготовки сценариев теста

Эмуляция реальной нагрузки, близкой к проду

Мы снимаем реальную статистику с прода, эмулируется нагрузка, близкая к продуктивной системе

Удобство масштабирования

За счет автоматической генерации сценариев нагрузочный тест удобно масштабировать

Автоматический итерационный запуск

Без нужды в аналитиках

Нет необходимости привлекать аналитиков для составления сценариев

Использование реальных данных

В нагрузочном тесте используются реальные несинтетические данные

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

17_20_18_00_Доклад_Величаева_Литвинов_1_1_page-0013.jpg

Вводные данные

Конфигурация «1C:ERP Управление холдингом 3.1.5.6» с большим количеством доработок и расширений.
Версия платформы 1С:Предприятие - 8.3.20.19.14.
Размер базы – более 700 гигабайт.
Количество пользователей – более 500.
Цель нагрузочного тестирования – проверка возможностей перехода на Linux + PostgreSQL.

17_20_18_00_Доклад_Величаева_Литвинов_1_1_page-0014.jpg

Сценарии проведения нагрузочного теста

Для проведения нагрузочного тестирования было подготовлено два сценария:

Первый – это сценарий длительностью 1 час, эмулирующий ежедневную нагрузку на 500+ пользователей.
Второй – это выполнение длительной ресурсоемкой операции «Расчет себестоимости». Был установлен лимит выполнения 24 часа. По истечению этого времени тест завершался – независимо от окончания операции.

17_20_18_00_Доклад_Величаева_Литвинов_1_1_page-0015.jpg

Характеристики тестовых площадок

Было подготовлено три площадки:

Первая – это ОС Windows СУБД MS SQL (то, на чем сейчас работает заказчик).
Вторая – ОС Linux, СУБД PostgreSQL.
И третья, для сравнения – ОС Linux, СУБД Tantor.

Результаты и выводы

Что у нас получилось:

По первому сценарию лучше всего себя показал PostgreSQL, за ним Tantor – почти такой же результат и на третьем месте – MS SQL.
Если в целом анализировать операции первого сценария, то можно сделать вывод, что площадки на ОС Linux показали себя лучше или так же, как MS SQL
Второй сценарий был менее успешен
На MSSQL расчет себестоимости выполнялся около пяти часов. На Linux + PostgreSQL и на Linux + Tantor расчет себестоимости за 24 отведенных часа не выполнился.
Основные выводы: переход на ОС Linux без предварительной адаптации конфигурации невозможен и необходимы работы по адаптации конфигурации

Станислав Субботин

Руководитель корпоративного отдела Инфостарт

Есть вопросы по решению?
Хотите проверить свою систему?
Мы вам поможем!

Получите индивидуальную консультацию с экспертом по проведению нагрузочного тестирования вашей системы с ответами на все вопросы!

Статистика:
Просмотры	3079
Загрузки	0
Рейтинг	4
Комментарии	0
Создание	20.05.24 15:27
Обновление	20.05.24 15:27
№ Публикации	2105942
Характеристики:
Теги	Нагрузочное тестирование сценарий операции итерации
Рубрики	ФУНКЦИОНАЛЬНЫЕ
Кому	Системный администратор , Разработчик , Руководитель проекта
Тип файла	Нет файла
Платформа	1С:Предприятие 8
Конфигурация	1C:Бухгалтерия
Операционная система	Не имеет значения
Страна	Не имеет значения
Отрасль	Не имеет значения
Налоги	Не имеет значения
Вид учета	Не имеет значения
Доступ к файлу
Код открыт	Не указано