PERFORMANCE

Любое программное обеспечение должно работать под нагрузкой длительное время. Сбои и отказы системы могут привести к убыткам, потере клиентов и другим неприятным последствиям. Нагрузочное тестирование позволяет определить, как и с какой скоростью работает программа под определенной нагрузкой. Посредством нагрузочного тестирования оценивается соответствие производительности продукта требованиям, сформулированным в ТЗ.

Нагрузочное тестирование рекомендуется проводить при выпуске нового программного обеспечения, доработке эксплуатируемого ПО и при изменении конфигурации стендов.

Ключевые цели

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

Нагрузочное тестирование является сложным процессом, включающим в себя

⦁ аналитическую работу,

⦁ выбор подходящего вида тестирования под заданные цели.

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

Важность тестирования производительности

Тестирование производительности является неотъемлемым этапом оценки качества программных средств в силу следующих причин.

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

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

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

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

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

Виды нагрузочного тестирования

Performance Testing — собирательное название. Относительно недавно пришло на замену «чистому» определению Load Testing.

И сейчас часто употребляется как Load/Performance Testing.

Подразделы можно выделить такие:

Performance/Load Testing — снимаем характеристики, и при последующих билдах/патчах сраниваем новые со старыми.

Performance Testing

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

Load Testing

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

Scalability Testing (Тестирование масштабируемости) — ищем performance threshold(предел), докуда (No. of concurrent connections) infrastructure (или только application server) может выдерживать нагрузку.

Stress Testing (Стрессовое тестирование) — даем заведомо превышающую норму нагрузку. Это может быть слишком много юзеров, или слишком часто/быстро посылаем запросы. В результате, сервер часть запросов теряет, на часть отвечает невпопад… Как правило, стресс-тестирование проводится в следующих случаях:

⦁ Если велика стоимость отказа системы в экстремальных ситуациях.

⦁ Если есть возможность резкого увеличения нагрузки на систему в экстремальных ситуациях.

Endurance Testing (Тестирование на выносливость)— заставляем работать долго, очень долго, пока не вылезут ляпы ресурс-менеджемента. Memory Leakage (не всю память программа освобождает), например. Или сокеты открывали, но не закрывали. Или хэндлеры создавали, но не освобождали. А может банально пожрать все место на диске или в базе данных.

Volume Testing (Объемное тестирование) — задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения. Позволяет:

⦁ Определить глубину хранения данных, при которой не произойдет деградации производительности системы.

⦁ Подобрать оптимальный комплекс технических средств.

⦁ Выявить лучшее архитектурное решение для системы, находящейся на этапе проектирования.

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

Объемное тестирование рекомендуется основывать на следующих бизнес-прогнозах:

⦁ как увеличится число пользователей системы?

⦁ как увеличится интенсивность операций?

⦁ какой объем базы данных будет, например, через 5 лет?

Stability / Reliability Testing (Тестирование стабильности или надежности) — задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. В результате тестирования могут быть найдены многие трудноуловимые в обычных условиях ошибки, такие как утечка памяти, некорректные настройки серверного окружения, недостаток аппаратных или системных ресурсов. Позволяет:

⦁ Предупредить сбои системы и ухудшение скорости и качества обработки данных.

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

⦁ Определить характеристики системы, которые подлежат отслеживанию в ходе опытно-промышленной эксплуатации.

⦁ Выявить недостаток аппаратных и системных ресурсов до внедрения в опытно-промышленную эксплуатацию.

Другие реальные задачи для Performance Testing — поблочное тестирование элементов инфраструктуры, с целью выявления «узких» мест (bottlenecks). Firewall, Router, DB, etc.

Основные этапы нагрузочного тестирования

Подготовка — Проводится анализ целей и статистики эксплуатации системы. Определяются бизнес-операции, имеющие значение с точки зрения нагрузки на систему. Создается и согласуется документ «Методика нагрузочного тестирования», который включает: стратегию тестирования, список и описание тестов, критерии успешного завершения, описание средств мониторинга и инструментов нагрузочного тестирования. Осуществляется подготовка тестовых данных, настраивается мониторинг, наполняется база данных.

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

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

Проверка продуктивности сайта

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

Критерии продуктивности

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

Критерии продуктивности должны быть:

измеримыми,
количественными,
прогнозируемыми,
понятными.

Пример критериев

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

Делая вид, что основываются на этой информации, веб-строители выбирают подходящие инструменты и программное обеспечение. Например, мы верим в то, что система управления базами данных MySQL выдерживает, не кашляя, 200 одновременных запросов. Точнее, принимает и ставит сукиных детей в очередь. Значит, «Для обеспечения 150 одновременным запросов на разрабатываемом приложении мы выбираем MySQL!» говорят веб-строители, а потом оказывается, что надо было сразу выбирать Berkeley, но «Боржоми» уже закончилось…

Иногда разработчики ничего особо не выбирают, а пользуются тем, что есть и чем они умеют управлять…

Тестировщиков проблема выбора веб-строителей не волнует. Тестировщиков волнует проверка продуктивности этого творения.

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

бизнес процессы
инфраструктура
технологии

Что следует проверять

при перформанс-тестировании, уже придумано до и для нас:

Время отклика (Response time). Измеряется в секундах время между исходным запросом к серверу и его «окончательным» ответом клиенту во всех рабочих режимах — как в режиме нормальной нагрузки, так и в усиленном режиме, когда перегорают сразу все UPS в здании.
Максимально допустимая нагрузка (Load testing). Просто последовательно увеличиваем нагрузку с нуля до «допустимых» параметров. Основной вопрос, на который мы пытаемся ответить посредством лоад-тестинга: «Как изменяется время отклика при увеличении нагрузки на сервер — линейно или по-дурацки?» Линейно: если время отклика растет пропорционально увеличению нагрузки — Это нормально. По-дурацки: если время отклика растет непропорционально увеличению нагрузки. Начинаются задумчивые, непрогнозируемые, неконтролируемые «тормоза». Иногда вместо «по-дурацки» говорят «логарифмически». Пример: «Время отклика растет логарифмически!» Уточнение: лоад-тестинг является составной частью всеобщего перформанс-тестинга.
Максимально выдерживаемая нагрузка (Stress testing). Делаем то же самое, что и при load testing, просто не останавливаемся, когда доходим до предполагаемых пределов. Продолжаем увеличивать нагрузку. Доводим сервачок до истерики. Получаем информацию о том, как он себя поведет, когда нагрузка превысит расчетные нормы. Узнаем, до каких масштабов сервер (ну, или приложение) будет стараться работать, и на каких значениях оно откажется нам служить. Таким образом, разница между Load и Stress testing в перформансе очень субъективна. В действительности разница в том, что Load приносит нам информацию о поведении приложения «в рамках ожидаемого», а stress приносит нам информацию о поведении приложения при пересечении этих «рамок».
Среднее время наработки на отказ (Mean time to failure (MTTF)). Разработчики клянутся в том, что при нагрузке в 300 активных пользователей сервер «будет беспроблемно жить в течение часа, пока кэш не переполнится». Тестировщики начинают подсчитывать: час — 300 юзеров. Значит, 600 юзеров «убьют» приложение за полчаса. А 1200 юзеров убьют сервер моментально! Или нет: час = 300 юзеров. А если два часа держать сервер под этой нагрузкой? А если три? А если шесть часов держать сервер под таким массивом запросов — он рухнет? Нет? Давайте проверять. А давайте узнаем, сколько времени будет «безотказно» работать сервер с базой данных отдельно от сервера с приложением! А процессор не перегреется? В общем, на основе собственных знаний, инженеры предполагают, что в течение недели сервер будет «стабильно» жить под пиковой нагрузкой в 300 запросов в течение часа. Нормально? Это предсказывали? Это и проверили?Для тестирования веб-серверов MTTF может и не быть очень важной проверкой. Если сдох — ну, ребутнём его… Но, например, без тестирования на MTTF систем, которые будут работать далеко от разработчиков (в космосе), фэйл может быть буквально трагичным.
Настройка продуктивности (Performance tuning). Звучит странно, но тут действительно подразумевается конечная подстройка производительности тестируемого сервера. Тестировщики СОВМЕСТНО с разработчиками настраивают и в сотый раз перепроверяют работу сервера с учетом сделанных изменений. Сами по себе тестировщики здесь беспомощны.
В тысячный раз увеличивается нагрузка на сервер до тех пор, пока все «узкие места» не объявлены «выявленными и ликвидированными». Или «выявленными, но признанными недопустимыми».

Вариант 1: идеальная система

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

Вариант 2: высококачественная система

В отличие от идеальной системы, данная система показывает характерные отклонения от идеальных показателей производительности и использования системных ресурсов.

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

Вариант 3: низкокачественная система

После достижения точки насыщения все характерные показатели производительности системы носят ярко выраженный случайный характер.

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

Вариант 4: крайне низкокачественная система

Cистема вышла из строя через 170 секунд после начала эксперимента.

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