Войти
. Проектирование производительности охватывает методы, применяемые в течение жизненного цикла разработки системы для обеспечения нефункциональные требования к производительности (такие как пропускная способность, задержка или использование памяти ) будут выполнены. В качестве альтернативы он может называться разработка производительности системы в рамках системная разработка и разработка производительности программного обеспечения или разработка производительности приложений в рамках разработка программного обеспечения.
По мере того, как связь между успехом приложения и успехом в бизнесе продолжает получать признание, особенно в мобильной сфере, инженерия производительности приложений играет превентивную и совершенствующую роль в жизненном цикле разработки программного обеспечения. Таким образом, этот термин обычно используется для описания процессов, людей и технологий, необходимых для эффективного тестирования нефункциональных требований, обеспечения соответствия уровням обслуживания и оптимизации производительности приложений перед развертыванием.
Термин «проектирование производительности» охватывает больше, чем просто программное обеспечение и вспомогательную инфраструктуру, и поэтому термин «проектирование производительности» предпочтительнее с точки зрения макросов. Соблюдение нефункциональных требований также подтверждается после развертывания путем мониторинга производственных систем. Это часть управления ИТ-услугами (см. Также ITIL ).
Инженерия производительности стала отдельной дисциплиной в ряде крупных корпораций, где задачи выполняются отдельно, но параллельно с системной инженерией. Он широко распространен и включает людей из нескольких организационных единиц; но преимущественно внутри организации информационных технологий.
Поскольку эта дисциплина применяется в рамках нескольких методологий, следующие действия будут выполняться на разных этапах. Однако, если этапы рационального унифицированного процесса (RUP) используются в качестве основы, то действия будут происходить следующим образом:
Во время первой, концептуальной фазы программы или проекта, определены критические бизнес-процессы. Обычно они классифицируются как критические на основании значения дохода, экономии затрат или другой присвоенной бизнес-ценности. Эта классификация выполняется бизнес-подразделением, а не ИТ-организацией. В настоящее время выявляются и описываются риски высокого уровня, которые могут повлиять на производительность системы. Примером могут быть известные риски производительности для системы конкретного поставщика. Наконец, для этапа проработки определяются действия по производительности, роли и результаты. Действия и загрузка ресурсов включены в планы проекта на этапе разработки.
На этом этапе определения критические бизнес-процессы разбиваются на критические варианты использования. Случаи проверки будут далее декомпозироваться по мере необходимости на переходы на одну страницу (экран). Это варианты использования, которые будут подвергаться управляемому сценарием тестированию производительности.
Тип требований, относящихся к проектированию производительности, - это нефункциональные требования или NFR. В то время как функциональное требование относится к тому, какие бизнес-операции должны выполняться, нефункциональное требование, связанное с производительностью, будет относиться к тому, насколько быстро эта бизнес-операция выполняется при определенных обстоятельствах.
В начале этого этапа требуется ряд действий, связанных с инструментами повышения производительности. К ним относятся:
Группа тестирования производительности обычно выполняет тесты производительности не в среде разработки, а в специализированной среде перед развертыванием, которая настроена как можно ближе к запланированному производству среда. Эта группа выполнит тестирование производительности по сравнению с тестовыми примерами, подтверждая соответствие критических вариантов использования указанным нефункциональным требованиям. Команда выполнит нагрузочное тестирование как для ожидаемой (средней), так и для пиковой нагрузки. Они часто запускают стресс-тесты, которые выявляют узкие места в системе. Собранные данные и результаты анализа будут возвращены группе, которая выполняет настройку производительности. При необходимости система будет настроена для приведения тестов на несоответствие в соответствие с нефункциональными требованиями.
Если инженерия производительности была должным образом применена на каждой итерации и каждой фазе проекта к этому моменту, мы надеемся, что этого будет достаточно для того, чтобы система могла получить сертификат производительности. Однако, если по какой-то причине (возможно, не были применены надлежащие рабочие методы проектирования производительности) есть тесты, которые нельзя настроить на соответствие, тогда необходимо будет вернуть части системы в разработку для рефакторинга. В некоторых случаях проблема может быть решена с помощью дополнительного оборудования, но добавление дополнительного оборудования быстро приводит к снижению отдачи.
На этом заключительном этапе система развертывается в производственной среде. Требуется ряд подготовительных шагов. К ним относятся:
После развертывания новой системы текущие операции повышают производительность, в том числе:
В рабочей области (развертывание после производства) выполнять Основное внимание в проектировании уделяется трем областям: управление уровнем обслуживания, управление мощностью и управление проблемами.
Управление уровнем обслуживания В области проектирования производительности речь идет о соглашениях об уровне обслуживания и соответствующем мониторинге систем, который служит для проверки соответствия уровня обслуживания, обнаружения проблем и выявления тенденций. Например, при развертывании реального мониторинга пользователей можно гарантировать, что транзакции пользователей выполняются в соответствии с указанными нефункциональными требованиями. Время ответа транзакции регистрируется в базе данных, так что запросы и отчеты могут выполняться по данным. Это позволяет анализировать тенденции, что может быть полезно для управления мощностью. Когда пользовательские транзакции выходят за рамки допустимого диапазона, события должны генерировать предупреждения, чтобы можно было обратить внимание на ситуацию.
Для управления мощностью проектирование производительности фокусируется на обеспечении того, чтобы системы оставались в пределах соответствия производительности. Это означает выполнение анализа тенденций для данных, созданных за прошлые периоды мониторинга, так что будущее несоблюдения требований можно предсказать. Например, если в системе наблюдается тенденция к замедлению обработки транзакций (что может быть связано с увеличением размеров набора данных, увеличением числа одновременных пользователей или другими факторами), то в какой-то момент система больше не будет соответствовать критериям, указанным в соглашения об уровне обслуживания. Управление мощностью отвечает за обеспечение того, чтобы дополнительная емкость была добавлена до этой точки (дополнительные процессоры, больше памяти, новая индексация базы данных и т. Д.), Чтобы линии тренда были сброшены, и система оставалась в пределах указанного диапазона производительности.
В области управления проблемами методы проектирования производительности сосредоточены на устранении основной причины проблем, связанных с производительностью. Как правило, они включают настройку системы, изменение параметров операционной системы или устройства или даже рефакторинг прикладного программного обеспечения для решения проблемы низкой производительности из-за плохого дизайна или неправильной практики кодирования.
Для обеспечения надлежащей обратной связи, подтверждающей, что система соответствует указанным в NFR показателям производительности, любая основная система нуждается в подсистеме мониторинга. Планирование, проектирование, установка, настройка и управление подсистемой мониторинга определяются соответствующим образом определенным процессом мониторинга. Преимущества заключаются в следующем:
Этот компонент анализа тенденций нельзя недооценивать. Эта функциональность, если она реализована должным образом, позволит прогнозировать, когда данное приложение подвергается постепенно возрастающей пользовательской нагрузке, а растущие наборы данных будут превышать указанные нефункциональные требования к производительности для данного варианта использования. Это позволяет правильно составлять управленческий бюджет, приобретать и развертывать необходимые ресурсы для поддержания работы системы в рамках параметров нефункциональных требований к производительности.
