Файл: Тестирование производительности программ: подходы в зависимости от категорий приложений.pdf

3. ТЕСТИРОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

В настоящий момент наиболее исследованными направлениями тестирования, затрагивающими показатели производительности программных средств, являются:

• тестирование производительности (performance testing) – исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке;
• нагрузочное тестирование (load testing) – исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение «запаса прочности»);
• стрессовое тестирование (stress testing) – исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень;
• объёмное тестирование (volume testing) – исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.

Цели различных видов тестирования производительности

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

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

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

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

Тест на определение максимальных возможностей системы (capacity test) позволяет определить т.н. «точку насыщения системы» (system saturation point) – уровень нагрузки, при котором дальнейшее наращивание числа пользователей ведёт к увеличению времени отклика системы либо ухудшению стабильности системы, но не к увеличению в единицу времени количества полезных операций, обработанных системой. Данный тест направлен на оценку производительности системы как аппаратно-программного комплекса, поскольку учитывает доступные аппаратные ресурсы и эффективность их использования.

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

Низко-, средне- и высоконагруженная работа (low-, mid-, high-load tests) – позволяет оценить время отклика (response time) системы в некоторых заданных диапазонах нагрузки. Данная информация может быть использована при составлении перечня требований к условиям эксплуатации системы.

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

Тест «часа пик» (rush hour test) позволяет оценить реакцию системы на резкое изменение нагрузки. Во время теста проверяется способность системы выдержать скачкообразное увеличение нагрузки во время «часа пик», а также способность системы вернуться к изначальным показателям производительности после завершения «часа пик» (восстановления исходных показателей нагрузки на систему). Такой тест позволяет выявить проблемы с синхронизацией выполнения отдельных участков кода, а также проблемы с управлением всеми видами межкомпонентного взаимодействия (в т.ч. сетевых и локальных соединений) на всех уровнях системы.

Тест «точки рандеву» (rendezvous point test) подразумевает такую настройку профиля нагрузки и поведения виртуальных пользователей, чтобы в некоторый момент все они одновременно выполняли одну и ту же операцию: как правило, синхронную операцию сохранения, записи, и т.п. В отличие от теста «часа пик» этот тест не подразумевает увеличения числа одновременно работающих с системой пользователей, а подразумевает исследование ситуации конкуренции пользователей за некоторые ресурсы, совместное использование которых не представляется возможным или сопряжено с повышенной нагрузкой на системные ресурсы. В частности, этот тест позволяет выявить проблемы с разделением ресурсов на уровне баз данных.

3.3 Примеры тестирования на производительность

Обслуживание пользователя - это всегда последовательность задач.

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

1. HTTP POST request
2. Find and load Session
3. Check Permissions
4. Try load object from Cache
5. Load object from Database
6. Write to usage tracking log
7. Send Request back to client.

Рис. 1. Конвейер задач

Каждая задача имеет «длину», т.е. продолжительность задачи в миллисекундах.

Каждая задача имеет «ширину», т.е. затраты процессорного времени/памяти/производительности дискового ввода-вывода.

Рис. 2. Продолжительность задач

Суммарная продолжительность задач при выполнении одного запроса – это скорость, с которой приложение отвечает пользователю (Response time, оно же Latency). Это то, что конечный пользователь называет производительностью.

Количество запросов, которое приложение способно выполнить в минуту (час/день), обслуживая необходимое для бизнеса количество пользователей(скажем 10 000) – это пропускная способность (Bandwitch).

Пример: «1 миллион просмотров страницы товара в сутки, при количестве одновременных пользователей до 10 000».

От чего будет зависеть пропускная способность?

• От «пространства», которое приложению требуется, чтобы обслужить одни запрос, т.е. произведения ширины и длины задач.

Например, чем больше CPU time (RAM/Network bandwitch, и т.д.) приложению требуется для задачи «Проверить наличие товара на складе» (или чем дольше оно эту задачу выполняет) - тем меньше его остается для обслуживания других пользователей.

• От пропускной способности «трубы» (pipe) в которой запросы выполняются. Больше места в «трубе» – больше запросов можно обслужить одновременно. Пропускную способность «трубы» определяют, прежде всего, аппаратное обеспечение (hardware), потом OS и Middleware.

Рис. 3. Пропускная способность трубы

Виды ресурсов и фундаментальные ограничения

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

• Если система имеет высокую производительность на максимальном количестве пользователей - это не означает что она не имеет проблем на среднем.
• Нужно знать, достигнут ли «потолок», насколько большой запас производительности имеется в системе.

Показатели, которые следует измерять для нагрузочного тестирования:

1. Скорость ответа (далее Latency) - какая средняя скорость ответа? Какая максимальная и минимальная?
2. Пропускная способность(далее Bandwitch) - сколько запросов в минуту выполнено?
3. Количество ошибок (далее Error rate) - сколько запросов приложение не смогло выполнить?

Когда система подвергается большей нагрузке, чем способна обработать, у нее есть три варианта поведения:

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

Пример: Наш электронный магазин предоставляет HTTP REST API партнерам, позволяя им закупать у нас товары оптом. Наш сервер API способен обслуживать 40 одновременных запросов. Что произойдет, когда мы получим одновременно 41 запрос? Нам придется поставить один запрос в очередь, и заставить его ждать, пока не освободится какой то из потоков, которые обслуживают сейчас предыдущих 40 пользователей. А если мы получим 60 одновременных запросов? Поставим в очередь 20 из них.

1. Правильный. Если количество запросов настолько велико, что их невозможно обработать за требуемое время - отбрасывать запросы

Пример: Продолжая пример выше, что, если мы получим 240 запросов? Мы конечно можем поставить 200 запросов в очередь, но чем больше у нас ожидающих в очереди, тем хуже средняя скорость ответа. С точки зрения пользователя, система которая «зависла», т.е.,отвечает слишком медленно, ничем не лучше системы которая «сломана», т.е., не отвечает вообще. (Да, с точки зрения инженера, который обслуживает системы и знает их изнутри, разница большая, но заказчика это не интересует). Система, которая сразу сигнализирует о том, что перегружена/получила больше работы, чем может выполнить в срок, намного лучше, чем та которая молча заставляет клиентов ждать слишком долго/вечно. Нужно поставить лимит на длину очереди и отбрасывать (например, через HTTP 500) запросы которые не уместились в нее.

Если SLA(Service Level Agreement) «запрос должен быть обработан не больше чем за 6 секунды» и скорость выполнения запроса 3 секунды - какая максимальная длина очереди имеет смысл? Ответ – 40. Более длинная очередь не позволит выполнить SLA.