Нагрузочные тесты (не) нужны?!

Немного личного контекста

В нагрузочном тестировании я работаю уже более восьми лет и успел побывать в разных ролях: разработчика, исполнителя, заказчика и эксперта-консультанта.

Если оглянуться еще дальше, около 15 лет назад в Хабаровске мы с коллегой проверяли, будет ли 1С:Торговля и склад 9.2 работать под Linux. Тогда мы не знали новомодных слов «импортозамещение» и не думали, что занимаемся в каком-то виде нагрузочным тестированием. Мне кажется, что именно эти эксперименты во многом определили вектор моего развития в сторону эксперта по техвопросам.

Тезис «Нагрузочные тесты не нужны» я слышал множество раз от самых разных людей. Когда-то я был категоричен в своем мнении «Безусловно нужны!».

Если отвечать на этот вопрос сейчас, спустя время и опыт, мой ответ будет таким: «Скорее нет, чем да.»

Прежде чем хвататься за вилы и разводить костры, давайте разберемся подробнее.

Когда нагрузочные тесты действительно не нужны

За годы практики для себя я сформировал список ситуаций, в которых нагрузочное тестирование действительно можно не проводить.

1. Небольшие системы

Если в системе работает небольшое количество пользователей, а объем базы данных мал, серьезных нагрузок просто нет. Большинство проблем проявятся:

• при обычном сценарном тестировании;

• в ходе повседневной работы пользователей.

В таких случаях нагрузочное тестирование чаще всего избыточно.

2. Осознанный финансовый риск

В крупных проектах все упирается в деньги.

Важно сопоставить:

• стоимость простоя системы;

• стоимость ошибки;

• стоимость разработки нагрузочного теста (разовую);

• стоимость его актуализации и регулярного прогона.

Если разработка и поддержка нагрузочного теста дороже потенциального ущерба, и заказчик готов принять риски – тестирование можно не проводить.

3. «Системы-единороги»

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

Эксперты подключаются к ним в основном при инфраструктурных проблемах, а не из-за производительности.

4. Когда уже поздно

Иногда времени уже просто нет.

Пример из практики: нас подключают к проекту за месяц до запуска. Очевидно, что за это время сделать полноценный нагрузочный тест невозможно. Было принято решение:

• запускаться без нагрузочного теста;

• подключить экспертов к поддержке после запуска.

Критические проблемы устранили в первые дни, проблемы производительности – в течение нескольких недель.

!!! Такой подход возможен только при соблюдении двух условий:

• у вас есть сильные технические эксперты (и у них есть время);

• заказчик готов к рискам и проблемам (а они будут 100%) и доработкам уже после запуска.

Основные виды нагрузочного тестирования

Конечно же, нагрузочное тестирование, как вид, появилось не в 1С.

У нас в 1С чаще всего используются несколько типов:

1. Тестирование производительности

Базовый и самый распространенный вид. Проверяем, укладываются ли ключевые операции во временные нормативы при заданной нагрузке.

2. Тестирование стабильности

Проблемы часто проявляются не через час, а через 8, 16 или 24 часа непрерывной работы.

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

Чаще всего выявляются проблемы:

• утечки памяти;

• деградация производительности;

• накопление ошибок.

3. Стресс-тестирование

Позволяет безопасно увидеть, как система ведет себя при кратном увеличении нагрузки.

4. Тестирование отказоустойчивости

Здесь мы целенаправленно ломаем систему:

• отключаем серверы 1С;

• проверяем корректность настроек ТНФ;

• анализируем поведение полнотекстового поиска, журнала регистрации;

• проверяем корректность переключения нод СУБД.

5. Тестирование объемов данных

Система живет годами, а не месяцами. Базы в 100 ГБ, 1 ТБ, 10 ТБ – это принципиально разное поведение СУБД.

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

Подходы к разработке нагрузочного теста

Все подходы можно условно расположить по возрастанию стоимости и сложности.

Критерии оценки

Мы будем сравнивать подходы по следующим параметрам:

• скорость и простота разработки;

• изменение интенсивности;

• изменение длительности;

• масштабируемость;

• вариативность сценариев;

• повторяемость;

• полнота покрытия.

Срез действий пользователей на рабочей базе

Собирается реальный срез действий пользователей за рабочий день и затем воспроизводится на копии этой же базы на момент начала записи действий.

Плюсы:

• быстрая разработка;

• простая актуализация;

• хорошая повторяемость;

• максимальная близость к реальным действиям;

• можно тестировать фоновыми заданиями (исключается влияние клиентов и необходимость большого количества серверов-нагрузчиков).

Минусы:

• сложно масштабировать количество пользователей;

• сложно менять интенсивность;

• нельзя увеличить длительность теста;

• низкая вариативность.

«Частичный» нагрузочный тест

Тестируется отдельный фрагмент системы (обмен, отчет, операция).

Плюсы:

• быстро и дешево;

• гибкость и масштабируемость зависят от реализации;

• хорошая повторяемость.

Главный минус:

• Результаты нельзя напрямую экстраполировать на прод.

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

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

Работа с копированием и перепроведением реальных данных.

Плюсы:

• близость к проду;

• хорошая повторяемость;

• гибкость и масштабируемость;

• высокая полнота покрытия.

Минусы:

• сложная инициализация данных;

• высокая стоимость разработки и актуализации;

• чувствительность к изменению исходных данных.

Полноценный нагрузочный тест

Самый дорогой, но и самый надежный вариант.

Минусы:

• долго и дорого в разработке.

Плюсы:

• масштабируемость;

• гибкость;

• вариативность;

• повторяемость;

• полнота покрытия;

• удобная актуализация.

Что должно быть в результатах нагрузочного тестирования

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

Условия проведения

• конфигурация инфраструктуры;

• версии платформы и СУБД;

• версия релиза конфигурации;

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

Требования к нагрузке

• общее количество пользователей;

• роли пользователей и их распределение;

• сценарии действий;

• фоновые операции (обмены, регламентные перепроведения и прочие неинтерактивные операции).

Контролируемые показатели

• общий APDEX;

• APDEX по ключевым операциям;

• показатели фоновых операций;

• нагрузка на оборудование (CPU, диски, сеть).

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

• APDEX общий;

• APDEX по каждой ключевой операции;

• показатели производительности фоновых операций;

• нагрузка на оборудование;

• экспертные рекомендации;

Почему здесь не указаны результаты ТЖ, результаты отчетов, анализы и так далее? Потому что для человека, который будет смотреть со стороны, это будет просто набор букв и цифр, который будет только бесполезно раздувать протокол.

Но сюда я все-таки отнесу рекомендации экспертов, которые будут основаны на тех самых ТЖ и пр.

• решение о выпуске в релиз и ответственные лица.

Советы и типовые ошибки

Основано (как и вся статья) на личном опыте.

• Фиксируйтесь на длительности теста, а не на количестве операций.

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

• Используйте коэффициенты интенсивности.

Это может быть как общий коэффициент интенсивности, так и индивидуальный. Он позволит вам без особых трудов скорректировать количество операций.

• Не забывайте про фоновые операции и отчеты.

Вроде «база» и все знают, но все же довольно часто встречаю эту проблему.

• Минимизируйте случайные величины.

Отклонение значения случайной величины в рамках пары десятков секунд полезна (ну или до 30% от ее абсолютного значения) – оно позволит сгладить пики в распределении операций нагрузочного теста. Но случайное значение от одной секунды до десяти минут сделает только хуже – ваш тест станет абсолютно неповторяемым на вменяемом отрезке времени.

• Меняйте только один параметр за один прогон.

Так будет сильно проще понять, что же именно повлияло на результаты теста.

Когда нагрузочные тесты все-таки нужны

Мы разобрали те варианты, когда можно не проводить нагрузочное тестирование. А теперь давайте подумаем, когда все-таки имеет смысл его проводить.

Нагрузочное тестирование рекомендуется проводить, если:

• Разрабатывается новая система с >100 одновременных пользователей.

• Обновляется платформа 1С.

• Меняется СУБД или ее версия.

• Изменяются настройки СУБД.

• Меняется инфраструктура.

• Существенно дорабатывается функциональность.

• Планируется рост нагрузки.

• Тест проводится регулярно для контроля состояния системы.

• Проверяется каждый релиз (или одновременно, т.к. SLA, TTM и прочее, понимаю).

Смысл нагрузочного тестирования

Для руководителей и владельцев систем

Для руководителя нагрузочное тестирование – это не бессмысленная активность, тратящая ресурсы, а инструмент управления рисками.

Оно позволяет:

• заранее оценить вероятность простоя и его стоимость;

• принимать обоснованные решения о запуске системы или релиза;

• понимать, какие проблемы являются архитектурными, а какие – эксплуатационными;

• аргументированно обсуждать бюджет на инфраструктуру и развитие системы.

Важно помнить: отсутствие (как и наличие) нагрузочного тестирования – это тоже решение, оно должно быть осознанным и зафиксированным.

Для архитекторов, экспертов, эксплуататоров

Для экспертов, архитекторов и эксплуататоров нагрузочное тестирование – способ проверить гипотезы:

• выдержит ли выбранная архитектура требуемую нагрузку;

• где находятся узкие места (платформа, код, СУБД, инфраструктура);

• как система ведет себя за пределами «нормального режима».

Нагрузочный тест дает не только цифры, но и материал для:

• архитектурных решений;

• выработки стандартов разработки;

• формирования технического долга в измеримом виде.

Для разработчиков

Для разработчиков нагрузочное тестирование – это обратная связь о качестве решений, которые невозможно получить на функциональных тестах.

На практике именно нагрузочные тесты выявляют:

• проблемы параллельной работы;

• проблемы производительности в эксплуатации, приближенной к реальной;

• избыточные обращения к СУБД;

• избыточные обращения к серверу 1С;

• тяжелые запросы;

• неоптимальные алгоритмы;

• влияние редких, но «тяжелых» операций.

Чем раньше разработчик видит эти проблемы, тем дешевле их исправление.

Для аналитиков

Что интересно, но и аналитикам будет полезно участие в процессе НТ. Оно позволяет глубже погрузиться в бизнес-процессы.

В начале разработки нагрузочного теста нам нужно будет ответить на вопросы:

• какие бизнес-процессы являются критическими/важными;

• какие операции являются ключевыми;

• какие роли создают основную нагрузку;

• какие сценарии работы пользователей в этих ролях;

• какие фоновые процессы критичны для бизнеса.

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

Итоговый вывод

Нагрузочные тесты – это не догма и не формальность.

Это инструмент, который:

• добавляет аргументов в диалог ИТ с бизнесом;

• снижает неопределенность при принятии решений;

• делает риски измеримыми;

• позволяет системе расти без неожиданных провалов;

• уменьшает вероятность возникновения проблем производительности и стабильности.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.