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

Инженерия производительности (англ. 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 согласно закону Амдала:

[math]\displaystyle{ S_p = \frac{1}{\alpha + \frac{1 - \alpha}{p}} }[/math]

В нашем примере мы получим:

[math]\displaystyle{ S_4 = \frac{1}{0,3 + \frac{1 - 0,3}{4}} = 2.105 }[/math]

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

Увеличив вычислительную мощность ещё в два раза, получится:

[math]\displaystyle{ S_8 = \frac{1}{0,3 + \frac{1 - 0,3}{8}} = 2.581 }[/math]

Таким образом вновь увеличив вычислительную мощность в 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.