Инженерия производительности (англ. 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 согласно закону Амдала : ${\displaystyle S_{p}={\frac {1}{\alpha +{\frac {1-\alpha }{p}}}}}$ В нашем примере мы получим: ${\displaystyle S_{4}={\frac {1}{0,3+{\frac {1-0,3}{4}}}}=2.105}$ Таким образом, увеличивая количество вычислительных ядер процессора в 4 раза приводит к увеличению производительности всего в два раза (с 1 до 2.105). И мы уже на пути к пониженной эффективности вычислительной мощности. Увеличив вычислительную мощность ещё в два раза, получится: ${\displaystyle S_{8}={\frac {1}{0,3+{\frac {1-0,3}{8}}}}=2.581}$ Таким образом вновь увеличив вычислительную мощность в 2 раза, мы получили прирост производительности на уровне 1/5 (с 2.105 до 2.581).

Перевод в эксплуатацию

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

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

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

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

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

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

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

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

Управление ёмкостью

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

Управление проблемами

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

Мониторинг

Любая большая система требует наличия мониторинговой подсистемы, обеспечивающей уверенность в наличии корректных статистических данных, позволяющих судить о соответствии системы нефункциональным требованиям. Планирование, инсталляция, конфигурация и контроль мониторинговой подсистемы осуществляется в рамках определённого Процесса Мониторинга, который имеет следующие преимущества:

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

См. также

• Тестирование программного обеспечения
• Нагрузочное тестирование
• Тестирование производительности
• Стресс-тестирование

Ссылки

• (рус.) - Багтрекеры, автоматизированное тестирование, нагрузочное тестирование, юзабилити тестирование, сообщества, печатные издания, книги
• (рус.)
• (рус.)

Литература

• Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М. : «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9 .