Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску


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

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

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

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

Цели инженерной деятельности [ править ]

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

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

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

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

Разработка [ править ]

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

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

Строительство [ править ]

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

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

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

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

Переход [ править ]

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

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

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

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

Управление услугами [ править ]

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

Управление уровнем обслуживания [ править ]

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

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

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

Управление проблемами [ править ]

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

Мониторинг [ править ]

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

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

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

См. Также [ править ]

  • Производительность Java
  • Масштабируемость
  • Качество программного обеспечения
  • Тестирование программного обеспечения
  • Веб-производительность

Ссылки [ править ]

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

Дальнейшее чтение [ править ]

  • Руководство по настройке производительности базы данных
  • Практический аналитик производительности - Сообщество инженеров по производительности и совокупность знаний
  • Методология проектирования производительности
  • Стратегия повышения эффективности
  • Модель зрелости производственного процесса
  • Книга о производительности каждого компьютера
  • Изучение UML для проектирования производительности
  • Введение в проектирование производительности на основе моделирования
  • Использование ITIL для повышения производительности приложений
  • Паттерны и практики Performance Engineering
  • Производительность и масштабируемость распределенных программных архитектур
  • Лучшие практики проектирования производительности (высокий уровень)
  • Программная инженерия и производительность: дорожная карта
  • Порочный круг производительности компьютерных систем и операционных затрат на ИТ
  • Команда разработчиков Microsoft Windows Server, заархивированная 4 мая 2010 г., размещена на Wayback Machine.
  • Сбор требований к производительности
  • Веб-службы тестирования производительности: стратегии и передовой опыт
  • Оценка эффективности системы управления воздушным движением с использованием стандарта измерения отклика приложений (ARM)
  • Интеграция управления производительностью в ITIL