Нагрузочное тестирование – ключ к стабильной работе системы 1С. В этом материале разбираем методики, типичные ошибки и реальные истории. Узнайте больше о том, как сделать так, чтобы ваши проекты работали без сбоев – запись вебинара ждет вас!
Сущность и значение нагрузочного тестирования
Нагрузочное тестирование – один из ключевых инструментов оценки готовности информационной системы к промышленной эксплуатации. Этот метод позволяет выявить и устранить проблемы производительности до запуска системы в работу.
Основная цель нагрузочного тестирования заключается не просто в проверке работоспособности системы под нагрузкой, а в выявлении и устранении узких мест в:
- программном коде;
- конфигурации оборудования;
- бизнес-процессах;
- архитектуре решения;
- системе прав доступа.
Классификация по целям:
- Специфическое тестирование – для определенного количества пользователей.
- Исследовательское тестирование – определение пределов системы.
Компоненты и этапы тестирования
Комплексный подход к нагрузочному тестированию включает следующие этапы:
- Предварительный анализ:
- выявление критически нагруженных операций;
- оценка интеграционных процессов;
- анализ фоновых и регламентных заданий.
- Планирование тестирования:
- разработка сценариев нагрузки;
- настройка тестового окружения;
- определение метрик оценки.
- Проведение тестов:
- эмуляция пользовательской активности;
- мониторинг ключевых показателей;
- фиксация результатов.
Методология проведения тестирования
Эффективное тестирование включает:
- постепенное наращивание нагрузки;
- моделирование пиковых нагрузок;
- проверку долговременной стабильности;
- анализ потребления ресурсов.
Важные аспекты реализации
Ключевые рекомендации:
- длительность тестирования – не менее 6 часов;
- комплексный анализ всех компонентов системы;
- отказ от экстраполяции результатов;
- детальная фиксация всех параметров.
Практический опыт и типичные проблемы
Анализ кейсов показывает типичные проблемы при нагрузочном тестировании:
- Нестабильность результатов – решается созданием специализированных механизмов синхронизации процессов.
- Неравномерная нагрузка – требует оптимизации распределения интеграционных процессов.
- Проблемы с блокировками – возникают при некорректной архитектуре обработки данных.
Ниже поделимся двумя историями из личного опыта: как искали проблему, на что обращали внимание и как сумели ее разрешить.
Реальные случаи из жизни тестировщика
Неоднородный тест
Одна из ситуаций, с которой мы столкнулись при нагрузочном тестировании: нужно было сформулировать работу на 400 (на тот момент) пользователей в конфигурации «Управление розницей». К ней были определенные требования: быстрая скорость набора пользователей, достаточно однотипные операции и при этом очень интенсивные обмены данными.
В системе провели нагрузочное тестирование с помощью тест-центра и выявили странную ситуацию: в некоторых случаях у нас возникали блокировки, а в некоторых нет; тест был неоднороден и не повторялся от случая к случаю. Мы не могли понять, в чем причина.
Оказалось, все очень просто. У нагрузочного тестирования есть несколько стадий: подготовка, инициализация, само тестирование, запись результата и удаление. Когда проходила инициализация и начиналось выполнение теста, мы включали регламентные задания. Но они отрабатывают не мгновенно, а спустя несколько секунд после запуска. Именно из-за этого тест был неоднородным.
Чтобы решить проблему, мы написали отдельную обработку, которая эмулировала автоматический запуск только регламентных заданий. Мы нашли, где у нас проблемы с блокировками, и устранили их; нашли дополнительное измерения, по которым стоило бы блокировать. До этого у нас получился слишком обширный регион блокировки; добавив измерение и переписав код, мы устранили проблему.
Вывод из этой истории: тест надо запустить несколько раз, даже если первый прошел удачно, и убедиться, что один и тот же тест не дает разных результатов.
Неравномерная нагрузка
Второй случай произошел в 2023 году. Мы делали нагрузочное тестирование в Министерстве здравоохранения: нужно было проверить работу 1500 пользователей, при этом все работало на Linux + PG.
В ходе нагрузочного тестирования выявили проблемы кода и проблемы полнотекстового поиска. Тогда мы эмулировали включение фоновых заданий по регламенту, а не через регламентные задания.
Выявили узкое место: неоднородность обработки количества данных регламентным заданием. В один момент документов было 500, в другой 0, в третий – 1000. Это нормальное поведение, но мы решили копнуть глубже и посмотреть, почему интеграция распределяется неравномерно и можно ли на это повлиять.
Оказалось, да – можно сделать все асинхронно. Мы настроили более плавное распределение, в результате нагрузка в пиковые минуты снизилась. После исправления тесты показали нормальные результаты. Но этим дело не кончилось.
Мы посчитали средние нагрузки и заметили, что идет неравномерное распределение операций и нагрузки внутри операции. Шаблоны документов, которые должны были проводиться, распределялись по времени неравномерно, и это приводило к серьезным проблемам с производительностью в плане блокировок.
Промоделировав такую ситуацию, нашли проблемы с взаимоблокировками. Заметить такие нюансы довольно сложно, такие моменты как раз и выявляются с помощью нагрузочного тестирования.
Экстраполяция: допустима или нет?
Есть мнение, что нагрузочное тестирование нельзя экстраполировать. Что, как правило, понимают под экстраполяцией 1С-специалисты: вы провели нагрузочное тестирование на 100 пользователей, а потом умножили результат на 10 и сказали, что для тысячи пользователей нужны такие показатели и ресурсы.
Так делать действительно нельзя, это не экстраполяция. Потому что это экстраполяция – очень тяжелый математический механизм, который, возможно, потребует сотни опытов и выведения уравнений. Методы математической экстраполяции уместно использовать, например, для запусков космического корабля и так далее.
В случае с нагрузочным тестированием использовать его точно не нужно, потому что это приведет либо к очень большим временным затратам, либо не выйдет достичь уравнения, которое бы ответило на вопросы, при каких значениях и переменных можно запустить тест на 10 тысяч пользователей.
Даже математически правильная экстраполяция не дает стопроцентной гарантии получения корректных результатов. Лучше провести нагрузочный тест на 10 тысяч пользователей, чем использовать экстраполяцию.
Заключение
Нагрузочное тестирование – это неотъемлемый этап подготовки системы к промышленной эксплуатации и завершающий этап перед входом в продакт. Правильно организованное тестирование позволяет:
- минимизировать риски при запуске;
- обеспечить стабильную работу;
- выявить и устранить узкие места;
- оптимизировать использование ресурсов.
Хотите узнать больше – получите запись вебинара
Еще более детально процесс нагрузочного тестирования разбирали 12 августа на бесплатном вебинаре «Как предотвратить 90% сбоев в 1С благодаря нагрузочному тестированию». Рассмотрели ключевые аспекты нагрузочного тестирования: от определения необходимости до организации процесса. Рассказали слушателям, в каких случаях НТ становится критически важным этапом проекта, как правильно анализировать данные для составления сценариев и какие источники информации использовать для максимально точных результатов.
Все подробности – в записи вебинара!
