Стратегии архитектуры для тестирования производительности

Применяется к данной рекомендации по эффективности производительности в Azure Well-Architected Framework:

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

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

Основные стратегии, описанные в этой статье, опирались на базовые методики тестирования, описанные в стратегиях архитектуры OE:09 для тестирования. Сначала рекомендуется ознакомиться с этой статьей. Рекомендации, приведенные в этом руководстве, относятся к производительности и сосредоточены на достижении целевых показателей производительности, чтобы рабочие нагрузки оставались в соответствии с изменяющимися бизнес-целями.

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

Установка измеримых целей для тестов производительности

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

Определите целевые показатели производительности и назначьте бюджеты. Определите и задокументируйте конкретные целевые показатели производительности, например количество одновременных пользователей, которые необходимо поддерживать. Убедитесь, что эти целевые показатели соответствуют целям уровня обслуживания (SLOS) и преобразуйте их в измеримые тестовые цели.

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

Например, можно задать бюджет 400 мс для времени отклика API, 150 мс для запросов к базе данных и 1% ограничение для неудачных запросов. При сбое теста можно проверить результаты каждого слоя в своем бюджете, чтобы определить, является ли проблема медленными ответами API, медленными запросами базы данных или всплеском ошибок.

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

Определите пороговые значения для каждой метрики, чтобы тесты выдают четкие результаты прохождения или сбоя. Если ваше SLO требует, чтобы 95% запросов завершались в течение 200 мс, установите пороговое значение времени отклика API на 200 мс для 95-го процентиля. Любой тестовый запуск, где 95-й процентиль превышает 200 мс, является сбоем.

Начинайте рано и тестируйте непрерывно

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

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

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

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

Тестирование в реальных условиях

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

Отразите вашу производственную среду

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

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

• Вычислительные номера SKU и конфигурации
• Параметры автомасштабирования
• Конфигурации кэширования
• Сетевые условия (задержка, пропускная способность)
• Внешние зависимости

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

Предотвращение смещения конфигурации. Смещение конфигурации может привести к вводящим в заблуждение результатам теста. Реализуйте автоматические проверки, чтобы проверить соответствие тестовой среды рабочей среде. Убедитесь, что перед выполнением тестов развертываются правильные версии.

Компромисс. Полная рабочая репликация для тестирования производительности значительно увеличивает затраты на инфраструктуру. Оцените, оправдывает ли риск проблем с производительностью в продакшн-среде затраты на выделенную инфраструктуру тестирования производительности для вашей рабочей нагрузки.

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

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

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

Тестирование в рабочей среде показывает характеристики производительности в фактических условиях, в том числе:

• Реалистичные шаблоны поведения пользователей и тома данных
• Истинные варианты задержки сети и пропускной способности
• Эффекты географического распределения
• Производительность и зависимости сторонних API
• Фактические характеристики кэширования и инфраструктуры

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

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

Риск: Тестирование рабочей среды напрямую влияет на реальных клиентов, так как это может создать дополнительную нагрузку и нарушить трафик. Всегда реализуйте меры защиты, ограничивайте воздействие и готовьте планы отката, чтобы минимизировать потенциальные последствия для бизнеса. Сбалансируйте преимущества реалистичного тестирования с потенциальным бизнес-воздействием, которое может нарушить работу живых пользователей.

Проверка изменений с помощью экспериментов на основе гипотез

Используйте эксперименты на основе гипотез, чтобы управлять тестированием производительности. Разрабатывайте эксперименты для оценки производительности так, чтобы они приносили значимые результаты.

Начните с ориентированной гипотезы о производительности рабочей нагрузки и определите измеримые критерии успеха, которые приводят к практическим решениям. Например, гипотеза может быть: "Добавление индекса в таблицу заказов сокращает время запроса на 70% при пиковой нагрузке". Базовый план — текущая схема, а вариант — схема с новым индексом. Выполните один и тот же нагрузочный тест для обеих версий. Захватить задержку запросов, использование ЦП базы данных и пропускную способность, а затем сравнить результаты, чтобы определить, имеет ли гипотеза правду.

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

Применение нескольких типов тестов производительности

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

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

Выберите типы тестов в зависимости от того, что необходимо проверить.

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

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

Компромисс. Для тестирования производительности во всех типах тестов требуется значительное время и инвестиции в инфраструктуру. Сопоставляйте свои инвестиции в тестирование с бизнес-рисками.

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

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

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

Тестовые данные должны выглядеть как реальные рабочие данные. Используйте синтетические данные, обладающие характеристиками производственных данных. Резервировать рабочие наборы данных (правильно анонимизированные) для определенных сценариев, таких как выделение управления данными, такими как согласованность транзакций, задержка и обработка объемов данных.

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

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

При тестировании под нагрузкой учтите реальные вызовы API сторонних производителей. Имитация внешних зависимостей делает тесты более быстрыми и прогнозируемыми, но она скрывает реальные проблемы с производительностью. Если приложение зависит от API обработчика платежей, проверьте с помощью реальных вызовов, чтобы понять сквозную задержку.

Использование результатов теста для руководства по проектированию решений

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

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

Записывайте метрики производительности во время начальных тестов. Эта запись представляет собой базовый снимок "нормальной" производительности. В последующих запусках сравните новые результаты с этим базовым показателем для обнаружения изменений производительности. Рассмотрите влияние пользователя, частоту, стоимость исправления и риск изменения критериев при анализе данных для понимания системного поведения в различных условиях. Найдите шаблоны, показывающие, где снижается производительность. Используйте это представление, чтобы определить приоритеты усилий по оптимизации.

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

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

Поддерживайте тестовые ресурсы в соответствии с текущими шаблонами использования

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

Организуйте наборы тестов по типу. Сохраняйте нагрузочные тесты, стресс-тесты и тесты выносливости в отдельных наборах. Не смешивайте их. Каждый тип имеет разные требования к настройке, длительность выполнения и критерии успешности. Упорядоченные наборы упрощают выполнение целевых тестов, сравнивают результаты между запусками и поддерживают каждый набор независимо.

Регулярно обновляйте тестовые данные. Устаревшие тестовые данные приводят к недостоверным результатам. Повторно создайте тестовые данные, чтобы отразить текущие характеристики производственных данных при изменении модели данных, росте томов данных или изменении демографических данных пользователей.

Просмотрите тестовые сценарии по мере развития рабочей нагрузки. Запланируйте регулярные проверки, чтобы гарантировать, что сценарии по-прежнему отражают фактическое использование. Сценарии становятся устаревшими как:

• Поведение пользователя с течением времени изменяется
• Изменения шаблонов трафика по мере роста базы пользователей
• Новые функции содержат различные шаблоны использования
• Масштабирование инфраструктуры в соответствии с новыми требованиями к емкости

Упрощение функций Azure

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

Azure Chaos Studio помогает внедрять в приложение реальные ошибки, чтобы можно было выполнять контролируемые эксперименты по внедрению ошибок. Эксперименты помогают измерять, понимать и улучшать устойчивость облачных приложений и служб.

Нагрузочное тестирование Azure — это служба нагрузочного тестирования, которая создает масштабную нагрузку на любое приложение. Нагрузочное тестирование предоставляет возможности для автоматизации нагрузочных тестов и их интеграции в рабочий процесс непрерывной интеграции и непрерывной доставки (CI/CD). Можно определить критерии теста, такие как среднее время отклика или пороговые значения ошибок, и автоматически останавливать нагрузочные тесты на основе определенных условий ошибки. Нагрузочное тестирование предоставляет панель мониторинга, которая предоставляет динамические обновления и подробные метрики ресурсов компонентов приложения Azure во время нагрузочного теста. Вы можете проанализировать результаты теста, определить узкие места производительности и сравнить несколько тестов, чтобы понять регрессию производительности с течением времени.

Azure Monitor — это комплексное решение для мониторинга для сбора, анализа и реагирования на данные телеметрии из облачных и локальных сред. Application Insights — это расширение Monitor, которое предоставляет функции APM. Application Insights можно использовать для мониторинга приложений во время разработки и тестирования, а также в рабочей среде.

Связанные ссылки

• Рекомендации по тестированию безопасности
• Рекомендации по проектированию стратегии тестирования надежности

Контрольный список эффективности производительности

Ознакомьтесь с полным набором рекомендаций.