Обеспечение и поддержание производительности
 Защита от снижения производительности во время использования системы и по мере ее развития. |
|---|
Разработка не является однократной попыткой. Это текущий процесс. Ожидайте изменения в производительности по мере изменения функций. Существует дисперсии в шаблонах и профилях пользователей, даже изменения в оптимизации в других компонентах Azure Well-Architected. Любые изменения могут напрягать ресурсы рабочей нагрузки.
Сейф охранять систему от изменений, чтобы она не возвращала целевые показатели производительности. Интеграция тестирования и мониторинга в процессе разработки. Протестируйте производительность системы в рабочей среде с реальной нагрузкой и имитируйте нагрузку с автоматизированным тестированием до рабочей среды. В обоих случаях для проверки следует использовать методики мониторинга.
На протяжении всего жизненного цикла разработки проводите различные типы тестов на разных этапах. На начальных этапах проверьте подтверждение концепции, чтобы убедиться, что результаты производительности не являются совершенно непредвиденными. По мере прогресса разработки проводите вручную тесты с низким уровнем усилий для установления эталонных показателей. На этапе сборки начните разрабатывать автоматизированные тесты производительности, которые оценивают задержку, уровни стресса, емкость нагрузки и другие характеристики, определенные в планах тестирования.
Мониторинг должен быть неотъемлемой частью этих усилий, а не изолированным упражнением. Вы можете увидеть, как система и ее ресурсы выполняются с течением времени. Затем их можно точно настроить, чтобы максимально повысить их ценность, и убедиться, что они продолжают соответствовать стандартам производительности.
Имейте в виду, что целевые показатели производительности зависят от времени в ответ на изменения. Обновите модель производительности на основе проверенных и отслеживаемых метрик. Четко указывает на увеличение, уменьшение или отсутствие влияния на производительность потоков.
Всегда быть готовым пересмотреть и сбросить ожидания с заинтересованными лицами бизнеса.
Пример сценария
Contoso Event Solutions предлагает продукт, который сотрудники входа в события могут использовать для сканирования билетов на мобильном устройстве и быстро разрешить вход в билетное место для тех, кто авторизован. Система доступна как в автономном режиме, так и в качестве облачной версии для мест, обеспокоенных дублированием билетов. Автономный режим является высокопроизводительным, но в интерактивном режиме отсутствуют его целевые показатели производительности. Команда разработчиков недавно инвестировала несколько циклов разработки для работы над ним, и теперь производительность значительно улучшается и соответствует целевым показателям. Бизнес-заинтересованные лица хотели бы расширить свою клиентскую базу для поддержки крупных мест в ближайшее время.
Тестирование производительности при разработке
Формализация тестов производительности в качестве шлюзов качества, которые могут утвердить или запретить повышение выпуска и окончательное развертывание в рабочей среде.
Эти проверка точки гарантируют, что каждый этап развертывания соответствует необходимым стандартам производительности, прежде чем перейти к следующему. Точки проверка помогают предотвратить непреднамеренное снижение производительности. Например, если производительность значительно ниже ожиданий, вы можете заблокировать выпуск до тех пор, пока не будут выполнены улучшения.
Задача Компании Contoso
- Команда потратила значительное время и усилия для достижения приемлемой производительности для онлайн-версии приложения, но у них нет системы в настоящее время, чтобы предотвратить регрессию.
- Следующая функция, с которой они планируют добавить, — это возможность выбора места, чтобы показать фотографию участника вместе с сканированием для дополнительной проверки. Существует риск того, что дополнительный поиск фотографий и скачивание замедлит процесс.
- Без официального процесса существует риск того, что производительность как сетевых, так и автономных версий может негативно повлиять на дополнительные функциональные возможности, и они могут снизиться ниже своих целей.
Применение подхода и результатов
- Команда интегрирует автоматизированные тесты производительности в конвейер сборки. Реализуя строгие условия на основе производительности "go/no-go" в конвейере сборки, команда более уверена в том, что новая функция не будет выпущена с регрессией производительности.
- Команда была мудрой для реализации этого тестирования, так как она поймала ошибку в последней версии сборки. Ошибка заставила приложение попытаться подключиться к Интернету, чтобы скачать изображение, пока сканер был установлен в автономном режиме, что привело к истечении времени ожидания при каждом сканировании билета. Перехват этой ошибки с помощью автоматического тестирования позволил команде исправить ошибку перед выпуском новой версии.
Оптимизация с помощью наблюдаемости
Настройте повторяемый процесс для мониторинга реальных транзакций в рабочей среде и отклонениях от целевых показателей производительности. Кроме того, используйте искусственные транзакции в рабочей среде и настройте оповещения мониторинга о регрессии производительности.
Вы хотите получить представление о фактической производительности системы под реальной нагрузкой, которая не может быть имитирована с помощью тестов. Затем вы можете заранее определить проблемы и области улучшения, такие как потенциальные узкие места, недоиспользуемые ресурсы и другие проблемы.
Задача Компании Contoso
- Во время события, в котором они используют проверку онлайн-билетов, серверная система активно используется.
- Существует система мониторинга производительности приложений (APM), но она не использовалась для мониторинга работоспособности рабочих транзакций.
Применение подхода и результатов
- Команда решила внедрить обновленные процессы для улучшения метрик работоспособности:
- Они настраивают оповещения на основе процентилей производительности и исходящего значения производительности. Нет оповещений указывает, что система выполняется в допустимых диапазонах для большинства проверок билетов.
- После завершения автономного события данные телеметрии для сканирования билетов отправляются в пакет, и эти метрики также проходят процесс поиска отклонений от приемлемой производительности.
- Команда также реализует тестирование искусственных транзакций для расширения мониторинга производительности. Так как почти все события происходят в выходные дни и вечером, команда использует искусственное тестирование транзакций на протяжении недели, чтобы создать более согласованные базовые показатели производительности.
Интеллектуальная обработка изменений рабочей нагрузки
Устранение эрозии производительности по мере увеличения использования, изменения функций и накапливается с течением времени для обеспечения производительности. Сбросить ожидания и установить новые целевые показатели, если тонкой настройки приносит только краткосрочные преимущества.
При внедрении этого подхода можно сохранить состояние производительности, прежде чем снижение производительности будет развиваться в проблемах, которые негативно влияют на взаимодействие с пользователем за пределы допустимого диапазона.
Изменение целевых объектов сбрасывает модель производительности, и вы не тратите время на оптимизацию системы, которая уже достигла своей емкости.
Задача Компании Contoso
- Команда по продажам была агрессивно подключена к новым местам событий в системе. Дела идут хорошо.
- Система мониторинга рабочей нагрузки начала заметить, что бюджет производительности становится съеденным в большее и большее время, даже без внедрения новых функций.
- Без изменения эта траектория может привести к неприемлемой регрессии в производительности, что ставит рабочую нагрузку под угрозу сбоя при возникновении инцидента.
Применение подхода и результатов
- Команда понимает, что по мере подключения клиентов механизм поиска данных для онлайн-событий выполняет очень большую проверку данных для многих запросов.
- Некоторые оптимизации запросов помогли сохранить увеличение использования от причинения дополнительного вреда. В ближайшие месяцы команда планирует разбивать различные события в разные секции данных, чтобы уменьшить потребность в сканировании запросов. Это обеспечит продолжение масштабирования рабочей нагрузки.
- Они также понимают, что они могут дополнительно оптимизировать систему для роста, удалив данные о билетах из старых событий. Поиск старых событий не является тем, что необходимо сделать системой проверки билетов, чтобы данные можно было переместить в хранилище, выделенное для создания отчетов и исторического поиска.