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

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

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

Цели Инженерии производительности

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

Подход Из-за того, что эта отрасль может быть применена в различных методологиях создания ПО, нижеописанные виды деятельности могут осуществляться на разных стадиях. В случае использования методологии rational unified process (RUP), порядок их следования будет следующим:

Начало На стадии разработки концепта приложения или проекта, идентифицируются критические бизнес-процессы. Классификация важности бизнес-процесса обычно основывается на объёме дохода, снижении затрат или других свойств значимых для бизнеса.

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

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

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

Типом требований, относящихся к Инженерии производительности, являются нефункциональные требования (или NFR). В то время, как функциональное требования определяет как должна выполняться бизнес-операция, нефункциональное требование, связанное с производительностью, определяет как быстро эта бизнес-операция должна работать под определёнными условиями.

"Определенные условия" должны быть жизненными.

Пример 1: Неверное требование: отклик системы на запрос пользователя не должен превышать 10 секунд. Верное требование: для сценария использования ABC, отклик системы на корректный запрос пользователя не должен превышать 5 секунд для нагрузки в 250 активно использующих систему пользователей и 2000 онлайн пользователей в 95% случаев; или не должен превышать 10 секунд для пиковой нагрузки в 500 активных пользователей и 4000 онлайн пользователей в 90% случаев.

Между этими двумя требованиями существенная разница: первый не приводит каких-либо условий, второй - четко определяет условия при которых система должна функционировать и может, в отличие от первого, иметь SLA; архитекторы и планировщики ёмкости системы могут спланировать и построить систему основываясь только на втором, верном, требовании; тестировщики могут придумать надежный тест производительности только для второго, верного требования.

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

Пример 2: За целый бизнес-день совершается 1200 транзакций A, 300 транзакций B и 3300 транзакций C; причем за первый час совершается 10% транзакций A, 20% транзакций B, и 5% транзакций C; за второй - 10% транзакций A, 25% транзакций B, и 50% транзакций C, и так далее

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

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

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

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

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

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

Выполнение В самом начале этого этапа ведётся подготовка инструментарии для анализа производительности, которая включает в себя: Выявление ключевых участников команды разработчиков, которые занимаются экспертизой в области выбранного инструментария Определение инструмента профилирования для компонентного unit-тестирования или unit-тестирования на стадии разработки. Определение инструмента для автоматического тестирования компонентов ; используется в случае когда ещё нет графического интерфейса для разрабатываемых компонент. Определение инструмента для автоматического покомпонентного тестирования серверной части системы. Определение мультипользовательского основанного на скриптах инструмента для тестирования системы; необходим для тестирования сценариев использования движимых переходом между экранами или элементарными переходами. Определение инструмента для тестирования базы данных Предоставление инструментов для тестирования производительности разработчикам Презентации и тренинги для разработчиков.

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

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

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

Пример 3: Предположим, мы можем улучшить работу 70% модуля, распараллелив её и запуская сам модуль на 4 ядрах процессора вместе 1. Если принять за α часть последовательных вычислений, тогда (1-α) составляет часть вычислений, выполняемых параллельно, и тогда максимальный прирост скорости может быть достигнут с использованием количества ядер P согласно закону Амдала:

В нашем примере мы получим:Таким образом, увеличивая количество вычислительных ядер процессора в 4 раза приводит к увеличению производительности всего в два раза (с 1 до 2.105). И мы уже на пути к пониженной эффективности вычислительной мощности.Увеличив вычислительную мощность ещё в два раза, получится:Таким образом вновь увеличив вычислительную мощность в 2 раза, мы получили прирост производительности на уровне 1/5 (с 2.105 до 2.581).''

Перевод в эксплуатацию В течение финального этапа система разворачивается на продакшн-конфигурации, что требует следующих подготовительных шагов: Конфигурация операционных систем, сетей, серверов (приложений, веб-серверов, баз данных, балансировщика нагрузки и т.д.) согласно базовым чеклистам и оптимизациям, сделанным в ходе анализа производительности на конфигурации для тестирования. Обеспечение настройки и функционирования всех инструментов мониторинга системы. Запуск статистики в базе данных после загрузки в неё продакшн-данных. При сопровождении системы после её запуска текущими задачами по производительности могут быть: Регулярный (еженедельный или ежемесячный) отчёт, который показывает, что скорость выполнения критических сценариев использования системы удовлетворяет нефункциональным требованиям. В случае, если сценарий использования выпадает из границ, определённых нефункциональными требованиями, оформляется дефект. Ежеквартальный анализ динамики развития проекта, используемый для задач по управлению ёмкостью системы.

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

Управление уровнем услуг