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

Performance engineering


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

По мере того, как связь между успехом приложения и успехом в бизнесе продолжает получать признание, особенно в мобильной сфере, инженерия производительности приложений превратилась в превентивную и эффективную[1] роль в жизненном цикле разработки программного обеспечения. Таким образом, этот термин обычно используется для описания процессов, людей и технологий, необходимых для эффективного тестирования нефункциональных требований, обеспечения соответствия уровням обслуживания и оптимизации производительности приложений перед развертыванием.

Период, термин инженерия производительности охватывает больше, чем просто программное обеспечение и вспомогательную инфраструктуру, и поэтому термин «проектирование производительности» предпочтительнее с точки зрения макросов. Соблюдение нефункциональных требований также подтверждается после развертывания путем мониторинга производственных систем. Это часть Управление ИТ-услугами (смотрите также ITIL).

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

Цели инженерной деятельности

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

Подход к проектированию производительности

Поскольку эта дисциплина применяется в рамках нескольких методологий, следующие действия будут выполняться на разных этапах. Однако если фазы рациональный унифицированный процесс (RUP) используются в качестве основы, тогда действия будут происходить следующим образом:

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

Проработка

На этом этапе определения критические бизнес-процессы разбиваются на критические. сценарии использования. Случаи проверки будут далее декомпозироваться по мере необходимости на переходы на одну страницу (экран). Это варианты использования, которые будут подвержены сценарию тестирование производительности.

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

Строительство

На раннем этапе этого этапа требуется ряд действий, связанных с инструментами производительности. К ним относятся:

  • Определите ключевых членов команды разработчиков как экспертов в предметной области для выбранных инструментов.
  • Укажите профилирование инструмент для среды разработки / тестирования компонентов.
  • Укажите инструмент автоматического тестирования производительности модуля (компонента) для среды разработки / тестирования компонентов; это используется, когда еще не существует графического интерфейса для управления разрабатываемыми компонентами.
  • Укажите автоматизированный инструмент для управления серверным модулем (компонентами) для среды разработки / тестирования компонентов.
  • Укажите автоматизированный многопользовательский сквозной инструмент, управляемый сценариями, для среды разработки / тестирования компонентов; это используется для выполнения сценариев использования, управляемых экраном.
  • Определить инструмент загрузки тестовых данных базы данных для среды разработки / тестирования компонентов; это необходимо, чтобы гарантировать, что оптимизатор базы данных выберет правильные пути выполнения, а также для обеспечения возможности повторной инициализации и перезагрузки базы данных по мере необходимости.
  • Разверните инструменты повышения производительности для команды разработчиков.
  • Членам команды разработчиков необходимо провести презентации и провести обучение по выбранным инструментам.

Группа тестирования производительности обычно выполняет тесты производительности не в среде разработки, а в специализированной среде перед развертыванием, которая настроена как можно ближе к запланированной производственной среде. Эта команда выполнит тестирование производительности против контрольные примеры, проверка соответствия критических вариантов использования указанным нефункциональным требованиям. Команда выполнит нагрузочное тестирование против обычно ожидаемой (средней) нагрузки, а также пиковой нагрузки. Они часто будут бегать стресс-тесты это позволит выявить узкие места в системе. Собранные данные и результаты анализа будут возвращены группе, которая настройка производительности. При необходимости система будет настроена для приведения тестов на несоответствие в соответствие с нефункциональными требованиями.

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

Переход

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

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

После развертывания новой системы текущие операции повышают производительность, в том числе:

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

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

В области эксплуатации (постпроизводственное развертывание) инженерия производительности сосредоточена в основном в трех областях: управление уровнем обслуживания, управление мощностью, и управление проблемами.

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

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

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

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

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

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

Мониторинг

Чтобы обеспечить надлежащую обратную связь, подтверждающую, что система соответствует указанным параметрам производительности NFR, любая основная система нуждается в подсистеме мониторинга. Планирование, проектирование, установка, настройка и управление подсистемой мониторинга определяются соответствующим образом определенным процессом мониторинга. Преимущества заключаются в следующем:

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

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

Смотрите также

Рекомендации

  1. ^ «Уроки банковской отрасли, извлеченные из аутсорсинга услуг тестирования», Gartner. 2 августа 2012 г.

дальнейшее чтение