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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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

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

Переход

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

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

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

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

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

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

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

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

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

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

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

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

Мониторинг

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

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

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

См. также

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

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

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