Тестирование и анализ производительности — тема, которую хотелось бы обсуждать побольше. Мы начинаем публикацию перевода руководства от небезызвестной команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод — спасибо Игорю Щегловитову из Лаборатории Касперского, нашему бессменному автору материалов про тестирование. Остальные наши статьи по теме тестирования можно найти по тегу mstesting
Введение
Анализ производительности – дисциплина сложная. Она изучает систему на предмет выполнения требований производительности и определяет причины, если эти требования оказываются не достигнутыми. Статья Performance Analysis Primer из этого цикла содержит введение в эту тему, описывая инструменты и подходы, применяемые в облачной разработке для того, чтобы достичь хорошей производительности.
Цель данного руководства – научиться исследовать производительность системы. В частности, в данном руководстве содержится описание ключевых метрик производительности, на которые вам следует обратить внимание, а также то, как использовать эти метрики для определения того, насколько хорошо работает ваша система.
Примечание: Многие проблемы производительности в крупных приложениях обусловлены тем, что они не воспроизводятся под сравнительно низкой нагрузкой, под высокой же (стрессовой) нагрузкой они приводят к существенному замедлению или сбоям системы. Важным аспектом разработки масштабируемых систем является предотвращение данных ситуаций. Чтобы помочь вам с этой задачей, мы опубликовали статью, содержащую набор анти-паттернов производительности для облачных систем (cloud-based anti-patterns).
Понятие ключевых показателей производительности
Производительность системы определяется следующими факторами:
- Сколько операций может выполнить система за определенный период времени? (пропускная способность)
- Сколько операций могут быть выполнены одновременно? (параллелизм)
- Как долго система выполняет операцию? (время отклика/задержка)
- Сколько резервной мощности требуется системе для обеспечения роста нагрузки? (запас ресурсов)
- Сколько исключений система генерит под нагрузкой? (частота ошибок)
Эти факторы могут оказаться очевидными, но, конечно, они будут меняться в зависимости от уровня нагрузки на систему. При достаточном количестве ресурсов и невысокой нагрузке большинство систем выполняет операции быстро. Критический момент наступает, когда нагрузка увеличивается до какого-то предельного уровня. Как система будет обрабатывать несколько миллионов параллельных запросов или запросов, потребляющих большие объемы доступных ресурсов? На графике показан типичный профиль функционирования тестового облачного сервиса, который принимает и обрабатывает запросы пользователей. График иллюстрирует, как пропускная способность и среднее время отклика изменяются с ростом пользовательской нагрузки. Данный график получен в процессе контролируемого нагрузочного тестирования. Горизонтальная ось – время. Тест предполагает, что для выполнения каждого запроса требуется примерно одинаковое время и количество ресурсов. Интервалы времени между запросами подчиняются нормальному распределению, что моделирует реалистичное поведение виртуальных пользователей.
Примечание: реалистичное пользовательское поведение является важной чертой нагрузочного тестирования. Без применения данного подхода результаты могут оказаться неверными. Дополнительные сведения см. в статье Editing Think Times to Simulate Website Human Interaction Delays in Load Tests Scenarios.
Профиль производительности в зависимости от пользовательской нагрузки для простого облачного сервиса
Сначала пропускная способность низкая, но при повышении нагрузки она растет до некоторого предела, который зависит от возможностей (емкости) самого сервиса. Эта емкость, скорее всего, задается на этапе разработки или определяется используемыми сервисом ресурсами. Она может быть ограничена:
- Объемом сетевого трафика между клиентами и сервисом
- Загрузкой процессора, количеством потоков и объемом доступной памяти
- Если сервис использует БД, то сюда можно добавить количество доступных подключений к БД, объем трафика между сервисом и БД и др.
- Емкостью внешних систем, от которых зависит сервис. Например, емкость Azure SQL Database определяется термином DTUs (Database Throughput Units). Если вы превышаете выделенный вам DTUs, то последующие запросы к БД не будут выполнены до приобретения дополнительной емкости. Другие службы имеют ограничения на физические ресурсы (потоки, память, соединения и тп)
Примечание: убедитесь в том, что инструмент, который вы используете для тестирования производительности, не выдает ложных результатов. Например, если инструмент не способен предоставить достаточное количества агентов тестирования, для моделирования требуемой нагрузки, то пропускная способность может быть определена неверно.
Однако этот график не всегда показывает полную картину. Несмотря на то, что на нем видна максимальную пропускную способность, латентность (задержка) с дальнейшим увеличением производительности будет расти. Это означает, что все больше и больше запросов будут попадать в очередь ожидания. В какой то момент эти запросы могут начать падать в таймауте и клиенту будут возвращаться соответствующие результаты. Помимо этого, если сервис использует веб-сервер, например, IIS, то после превышения предела внешних соединений самого веб-сервера последний начнет отвергать новые соединения.
Еще одно примечание: нехватку емкости сервиса, от которого зависит ваша система, называют «back-end pressure» (внешним давлением). Во многих системах такие сервисы часто является факторами, ограничивающими производительность. Эти сервисы часто являются внешними, их управление может быть передано (либо уже контролируется) другим лицам, которые могут повлиять на производительность.
Рисунок иллюстрирует профиль нагрузки той же тестовой облачной службы под высокой нагрузкой.
В этом графике видно, что, как только нагрузка достигает 600-та пользователей, запросы начинают падать в таймауте и система начинает генерировать исключения. Увеличение нагрузки приводит к увеличению генераций ошибок. Обратите внимание, что частота успешных запросов также будет падать. Отмечу, что среднее время запроса также падает, т.к. сервис очень быстро начинает отклонять запросы. Важный момент – измерение времени отклика не является показателем того, насколько система хорошо работает.
Еще одна сложность состоит в том, чтобы учесть, что система может быть достаточно устойчивой, чтобы восстановиться (хотя бы временно) и что число запросов, ожидающих в очереди исчезнет, а последующие запросы будут обработаны успешно. Система может войти в период, когда колебания частоты успешно выполненных запросов будут циклически сменяться интенсивностью отказов. На рисунке показан график, иллюстрирующий это феномен, который отражает антипаттерн Improper Instantiation.
Колебания частоты успешных и неуспешных вызовов сервиса под возрастающей нагрузкой
В этом примере система восстанавливается периодически, а затем опять падает. Обратите внимание, что частота исключений продолжает расти с каждым последующим пиком, это указывает на то, что в какой-то момент система полностью выйдет из строя.
Основная цель этих графиков – это подчеркнуть взаимосвязь между факторами, которые помогают определить «самочувствие» системы находящейся под нагрузкой: она либо здорова, либо вот-вот рухнет, либо что-то среднее. Нагрузочное тестирование в тестовой среде может помочь вам определить допустимую емкость ваших сервисов и оценить, понадобится ли вам масштабирование для того, чтобы удовлетворить требования производительности.
На графиках выше речь шла о простой (идеальной) ситуации, когда тестируемые сервисы изолированы. Но в реальном мире существуют проблемы посторонних шумов". Пользователи ведут себя непредсказуемо, и выполняют одновременно множество разнообразных операций. В этом случае производительность системы в произвольный момент времени будет определяться совокупностью точечных операций, выполняемых в это время.
Если пользователи начинают получать ошибки либо работа системы замедляется, то это может быть связано не с конкретным участком логики, но суммарной нагрузкой на систему. Всё это подчеркивает важность непрерывного мониторинга производительности. Если вы владеете точной и актуальной информацией о производительности, то вы сможете быстро реагировать на внезапные всплески пользовательской активности, требующие дополнительного объема ресурсов для обработки запросов. Данные о производительности, которые вы собираете, должны включать достаточное количество контекстной информации, чтобы можно было свести различные метрики в полноценное видение жизненного цикла системного процесса. Эта информация имеет жизненно-важное значение во время анализа производительности. Она помогает вам понять, как различные параллельные процессы, из которых состоит ваша система, могут сосуществовать, взаимодействовать и конкурировать друг с другом. Процесс сбора такой информации подробно описан в статье Performance Analysis Primer.
Разбор показателей по уровням абстракции:
В большинстве систем существует множество метрик, которые можно собирать и анализировать. Без тщательного рассмотрения вы очень легко можете потеряться во множестве собираемых данных либо пропустить важное значение, забыв собрать ключевые метрики. Классификация ниже помогает упорядочить метрики по определенным уровням абстракции. Осуществив правильное распределение, вы можете сфокусироваться только на тех данных, которые определяют производительность соответствующего уровня. В этой серии статей будут описываться следующие уровни абстракции:
- Client Metrics. Данные метрики сконцентрированы на измерении производительности клиентских приложений. Например, как долго клиентское приложение выполняет действия локально и обрабатывает ответ от серверной части. Эти метрики покрывают такие данные, как объем используемой памяти и загрузку CPU. На мобильном устройстве высокая загрузка CPU и частое использование сети может привести к уменьшению срока службы батареи, а использование слишком большого объема памяти вообще может помешать приложению запуститься.
- Business Metrics. Сюда включаются данные, определяющие бизнес-процессы. Они касаются деятельности конечных пользователей. Эти показатели должны включать ключевые бизнес-операции, которые выполняет система
- Application Metrics. Данные метрики сосредоточены на измерении активности и производительности прикладного уровня (исходный код приложения, фреймворк, среда исполнения, например .NET Framework, ASP.NET, CLR, и т.п.). Цель этих метрик – помочь вам исследователь поток выполнения вашего приложения при большом количестве параллельных запросов, проанализировать потребляемые ресурсы и оценить вероятность проблем с производительностью
- System Metrics. Это данные о производительности низкого уровня (уровень базовой инфраструктуры). Они обычно нацелены на ключевые показатели эффективности, связанные с памятью, сетевой утилизацией, активностью диска, использованием процессора
- Service Metrics. Сюда относятся данные, связанные с производительностью внешних сервисов, таких как Azure Storage, инфраструктурой обмена сообщений, внешним кэшем, БД и другими внешними сервисами, которые ваше приложение может использовать. Эти данные не отражают чистую производительность внешних сервисов, а всего лишь содержат информацию об исполнении запросов, которые ваша система им отправляет.
Спасибо за внимание. В следующей части мы рассмотрим эти метрики подробнее и перейдем к следующим темам.
Части статьи:
Анализ ключевых показателей производительности — часть 1
Анализ ключевых показателей производительности — часть 2, про анализ метрик пользовательских, бизнесовых и приложения
Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики.
