От автора: мы живем в эпоху, когда все, вовлеченные в жизненный цикл разработки систем, понимают свою роль в создании высокопроизводительной системы. Ответственность теперь лежит не только на команде Performance Engineering за измерение производительности системы, а также ее сертификацию за пару дней до выката продукта в продакшн.
На деле, старт практик разработки Agile & DevOps уделяет большое внимание раннему анализу производительности, что привело к изменению в должностных обязанностях инженера по производительности. Тем не менее, независимо от традиционного водопада и модели agile/devops разработки, принятие ранних методов тестирования и анализа производительность приводит к экспоненциальным преимуществам (более подробно раскрыла тему в «ключевые области, на которые стоит обратить внимание, при раннем тестировании производительности»).
Задача инженера по производительности оценить производительность системы в раннем жизненном цикле ПО, но иногда приоритеты меняются из-за организационных ограничений и ряда других ограничений в окружении. При измерении и сертификации производительности системы забывается много ключевых фактов. Некоторые из самых главных описаны в этой статье.
Измерение производительности как часть среды непрерывной интеграции
С наступлением веб 2.0 веб-страницы стали высоко динамическими и тяжелыми с клиентской стороны, поэтому нужен постоянный упор на достижение наилучшей производительности в интернете. Для успеха интернет-бизнеса очень важно минимизировать время ответа, воспринимаемое конечным пользователем.
Во время оценки производительности системы не учитывается много таймаутов по веб-производительности (клиентская производительность) в списке приоритетов, а также иногда это забывается до выката в продакшн. Это забывается из-за сложности распределенного веб-приложения, режимов доступности и высокой производительности. Влияние производительности, вызванное браузерами, мобильными устройствами или сетевыми типами, не воспринимается так серьезно во время анализа производительности. Недостаточно уделять время только серверной производительности для сертификации на многопользовательских уровнях нагрузки. Точно так же важно проводить тесты производительности во время регресса с помощью инструментов непрерывной интеграции для измерения отклонений в производительности в разных билдах. Тренды можно хранить в базах данных типа Graphite/InfluxDB и визуализировать в Grafana для создания интуитивных отчетов реальном времени. Существует множество онлайн инструментов анализа производительности.
Измерение различий в тестовых характеристиках производительности от продакшн среды
При измерении производительности сервера важно знать архитектуру тестовый среды и возможности сервера, а также различия этих характеристик по сравнению с архитектурой и возможностями продакшн среды. Иметь изолированную тестовую среду нужно обязательно. Также необходимо использовать схожу с продашкн среду или, хотя бы, знать разницу в производительности тестовой и продакшн среды.
Ниже приведены параметры среды тестирования:
Продакшн среда для проведения тестов производительности (в часы пик)
Облачная тестовая среда, схожая с продакшн
Уменьшенная в масштабе тестовая среда
Третий вариант самый распространенный, но в нем есть риск проецирования результатов тестирования со слабой среды на продакшн. Инженер по производительности ответственен за использование подходящих техник экстраполирования значений производительности на продакшн среду. При накладывании результатов тестирования производительности на продакшн среду необходимо учесть несколько факторов. Все они описаны в «как по-умному решать задачи связанные со средой для тестирования производительности».
Инструмент тестирования производительности – просто механизм. Он не умнее вас
Многие инженеры по производительности считают, что достаточно знать пару инструментов тестирования производительности. Но в реальности такие мысли приводят к серьезным проблемам с производительностью в продакшн, несмотря на измерения производительности. Инженер по производительности должен изучить архитектуру системы, стек технологий и другие свойства системы для построения правильный стратегии тестирования производительности для сертификации тестируемой системы. Обзор архитектуры приложения и инфраструктуры может выявить некоторые проблемы с производительностью и пропускной способностью, которые можно проверить в тестах производительности. О производительности следует думать с раннего жизненного цикла разработки ПО, а не за пару дней до выката в продакшн.
Существуют различные старые практики о том, какие виды инженерных работ можно выполнять на этапах жизненного цикла разработки системы, включая ранние спринты, когда система даже не доступна. Необходимо изучать шаблоны трафика и использования в реальном времени для завершения различных тестов, в том числе нагрузочных тестов, стресс-тестов, объемных тестов, спайк тестов, тестов выносливости и мощности и т.д. Не все приложения требуют все типы тестов. Для сертификации приложения по производительности, масштабируемости, доступности и емкости необходимо подключить соответствующие типы тестов на основе шаблона использования приложения и целей тестирования. По ссылке вы найдете простые советы по запуску реалистичных тестов производительности.
Использование точной и реалистичной модели рабочей нагрузки для тестирования производительности
Зачастую рабочая нагрузка сервера, используемого для проведения тестов производительности, не соответствует реалиям. Анализ ошибок производительности в продакшн раскрыл истину. Модель рабочей нагрузки не является ни реалистичной, ни математически обоснованной с помощью принципов теории массового обслуживания до проведения тестов производительности. Анализ логов трафика в продакшн может показать реальный шаблон доступа и уровень интенсивности трафика.
С одной стороны существует много научных статей и исследований о том, как точно имитировать виртуальных пользователей для имитации реалистичных шаблонов распределения пользователей и создания высокоточной модели рабочей нагрузки, но с другой стороны видно, что тесты производительности для критически важных приложений выполняются без правильного распределения пользователей по ключевым потокам. Множество научных методов и методологий были опубликованы пионерами в Computer Measurement Group (CMG) – некоммерческая организация для профессионалов в области производительности и мощности, а также в International Conference on Performance Engineering (ICPE). Они могут помочь в создании точной модели рабочей нагрузки.
Постоянное управление производительностью и мониторинг реального UX
Необходимо постоянно измерять конечную производительность (после выката в продакшн), чтобы сразу узнавать о потенциальных узких местах в производительности на уровнях, сети, браузера, мобильных устройств и т.д. Мониторинг конечных пользователей для понимания модели их передвижения может помочь в создании важного цикла обратной связи с командами дизайна и разработки. Установление соответствующих циклов обратной связи от продакшн мониторинга для улучшения производительности рабочей нагрузки и стратегии тестирования производительности поможет в проведении точной оценки эффективности. С появлением APM инструментов наблюдается более высокая осведомленность в обнаружении и проблемах производительности в продакшн. Время диагностики сокращается с нескольких дней до нескольких часов. Использование методов искусственного интеллекта и методов машинного обучения для мониторинга производительности обнаружения аномалий и прогнозирования производительности может еще больше укрепить вашу стратегию.
Соединение точек – результаты тестирования производительности и планирование пропускной способности приложения
Хотя в раннем тестировании производительности наблюдается понимание, но когда дело доходит до планирования пропускной способности приложения, все же существует распространенное заблуждение, что провайдер облачных услуг позаботится об этом. Независимо от внутренних центров обработки данных, частных или общедоступных облачных приложений, результаты тестирования производительности должны использоваться для анализа планирования емкости приложения для оценки емкости сервера для прогнозируемой бизнес нагрузки. Принятие простых принципов теории массового обслуживания может помочь в ускорении анализа производительности, который может обеспечить вклад в планирование емкости приложения. Простой пример – использование теории массового обслуживания для ускорения анализа производительности.
Мероприятия по планированию потенциала приложений должны вносить вклад в планирование пропускной способности инфраструктуры. Насколько нам известно, производительность системы не всегда линейна. Поэтому необходимо соответствующие модели и методы для прогнозирования различий в сценариях «что если» для управления эффективностью. Все дело в искусстве соединения точек, чтобы получить правильную картину для планирования активной мощности путем внедрения эффективных стратегий управления мощностями.
Использование моделирования производительности для соответствия тестам производительности
Многие инженеры по производительности считают, что моделирование производительности заменяет само тестирование производительности. Поэтому они спорят о точности моделей производительности по сравнению с фактическими результатами тестирования. Многие думают, что им это не подходит из-за сложных вычислений. Знание простых уравнений, связывающих различные показатели производительности, творит чудеса в анализе производительности. Инженеры по производительности должны понимать, как простые действия по моделированию производительности могут помочь ускорить ранний анализ проблем производительности. Модель производительности доступна для предсказания на этапе дизайна и разработки системы с точностью до 50-60%. Этого достаточно для первых тестов производительности. Моделирование производительности для инженеров по производительности.
Факты, описанные выше, кажутся довольно важными, но несмотря на это, они часто забываются или считаются менее приоритетными, что приводит к неполным и нереалистичным измерениям.
Ключевой вывод из опроса пользователей «State of Performance Engineering 2015-2016», проведенного HP – «существует четкая тенденция к значительно более широкому применению термина Performance Engineering».
Андреас Грабнер рассказывает об изменениях, которые происходят, а также о ключевых моментах, о которых должен помнить инженер по производительности в статье «Trades of a Performance Engineer in 2020»!
Несомненно, роли и обязанности инженеров по производительности расширяются, и мы должны ориентироваться на новые задачи, применяя интеллектуальные, инновационные и непрерывные методы измерения производительности, которые обеспечивают точную оценку эфективности.
Автор: Ramya R Moorthy
Источник: //calendar.perfplanet.com/
Редакция: Команда webformyself.
