Тестирование под нагрузкой. Обзор инструментов нагрузочного тестирования

Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV), использующих облачные технологии. В этом выпуске мы расскажем про применение облачных сервисов Visual Studio Team Services, Azure, Application Insights и других для профессионального нагрузочного тестирования коммерческих продуктов на примере AdvantShop – решения для электронной коммерции, разработанном на базе ASP.NET. Предыдущие статьи цикла вы всегда можете найти на Хабре по ссылке #isvcloudstory . - Владимир Юнев

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

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

Специалисты компании "Логрокон" производят тщательную подготовку к тестированию, которая включает:

1. Анализ требований и сбор информации о тестируемой системе
2. Определение целей нагрузочного тестирования
3. Конфигурация тестового стенда для нагрузочного тестирования
4. Разработка модели нагрузки (Профиль НТ)
5. Выбор инструмента для нагрузочного тестирования
6. Разработка методики нагрузочного тестирования.
7. Создание и отладка тестовых скриптов

Результаты тестирования оформляются в отчете, который содержит:

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

Перед нами была поставлена задача тестирования производительности интернет-магазина AdvantShop . На сегодняшний день рынок ИТ предоставляет большое разнообразие средств для проведения нагрузочного тестирования ПО. И первый вопрос, который необходимо было решить для себя – какому из инструментов проведения нагрузочного тестирования отдать предпочтение?

Вероятно, многие из вас слышали о таком средстве тестирования производительности как Load runner. Наличие большого числа Web-протоколов объясняется желанием разработчиков охватить большой спектр технологий и уровней «захвата» данных. Выбирая этот инструмент для проведения нагрузочного тестирования нужно определиться, что для нас важнее: нетребовательность к ресурсам или удобство создания, поддержки и использования скрипта. Оба критерия для нас важны при проведении нагрузочных испытаний, поэтому продолжим поиск подходящего для нас средства проведения тестирования производительности.

Помимо платных утилит для проведения тестирования производительности рынок предлагает и ряд бесплатных. Под обзор попал такой из бесплатных инструментариев как Apache JMeter. К сожалению, этот инструмент имеет достаточно много проблем и ограничений: он может не поддерживать необходимые протоколы; в нём отсутствуют удобные средства мониторинга; выдаваемые им результаты требуют дополнительной обработки. А поскольку специалисты «Логрокон» отвечают не только за качество услуг, но и за сроки их оказания - такому инструменту как Apache JMeter мы не отдали предпочтение для помощи в проведении работ по тестированию производительности интернет-магазина.

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

Тестирование «у себя» вызывает определенные трудности:

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

Однако с этими проблемами помогает справиться облачная служба Microsoft Azure , при использовании которой можно выделить очевидные преимущества перед тестированием «у себя» и использованием других доступных средств:

• Быстрый выход качественного продукта на рынок
• Цена. Отсутствие и устранение капитальных расходов при доступе к тестовому окружению в облаке, которое масштабируется лучше, чем собственное.
• Использование знакомых инструментов
• Лучшее тестирование с “бесконечным” облаком
• Изолирование продакшн-серверов . Предотвращение влияния процесса разработки и тестирования и тестовых приложений на серверы работающие в коммерческой эксплуатации в компании
• Доступ из облака к существующим мощностям в компании
• Размещение в любом месте без лок-ина

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

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

Безусловным преимуществом для выбора Microsoft Azure при тестировании производительности интернет-магазина AdvantShop является тот факт, что сервер приложений и сервер БД развернуты в Azure - это существенно упрощает развертывание инфраструктуры нагрузочного тестирования.

Средства Microsoft Azure позволяют выполнять нагрузочное тестирование с помощью Visual Studio Team Services (ранее сервис назывался Visual Studio Online), либо с помощью Virtual Machine.

Нагрузочное тестирование с помощью Visual Studio Team Services (VSTS) позволяет автоматически создавать и конфигурировать всю необходимую инфраструктуру в облаке, разворачивая контроллер и необходимое количество агентов с определенными настройками. Результаты прогона того или иного теста всегда остаются в облачной базе VSTS, и к ним в любой момент можно получить доступ. Помимо доступного развертывания инфраструктуры нагрузочного тестирования стоит обратить внимание на мониторинг приложений, поскольку при проведении нагрузочных испытаний тестировщик обращается к нему снова и снова. VSTS позволяет прямо в процессе нагрузочного тестирования динамически подгружать необходимые счетчики производительности из телеметрии Application Insights . Возможности Application Insights выходят далеко за рамки снятия метрик, настроенных в Performance Monitor непосредственно на серверах приложения. Имея доступ непосредственно к коду приложения, можно передавать в Application Insights данные об отслеживании событий, метрик, трассировки, зависимостей и тому подобное. Посредством такого подхода можно вычислить, к примеру, как часто пользователи выбирают определенный компонент, как часто они достигают определенной цели или как часто возникают те или иные ошибки.

И все-таки при выборе между VSTS и развертыванием Virtual Machine мы отдали предпочтение более знакомой нам классической инфраструктуре с агентами и контроллером, хотя средства VSTS ничем не уступают. При этом подходе помимо имеющихся серверов IIS и DB необходимо создать виртуальные машины для контроллера и агентов тестирования. На отдельную виртуальную машину имеет смысл вынести Visual Studio, поскольку при использовании VS локально можем столкнуться с проблемой нехватки ресурсов для обеспечения необходимой нагрузки на приложение.

Для корректной работы всех компонентов среды необходимо создавать виртуальные машины с такими же пользователями, что и машины с IIS и DB, а так же выдать необходимые права для снятия метрик производительности серверов.

При развертывании VM для контроллера

• TCP порт 445 для удаленного сборка счетчиков производительности
• UDP порт 1434 для SQL Browser и TCP 1433 для подключения к SQL серверу
• TCP порт для подключения к Test Controller`y 6901
• Remote Destop.

После настройки VM подключаемся к ней через RDP и устанавливаем TestController. Затем запускаем Test Controller Configuration Tools и указываем аккаунт, с которым подключались к виртуальной машине, отмечаем галочку Configure test controller for load testing. В строке SQL Server instance указываем полное DNS-имя VM (не localhost, а, к примеру, adv5controller.cloudapp.net\SQLExpress чтобы была возможность сохранять результаты теста при запуске VS с другой VM).

Загружаем и устанавливаем дистрибутив SQL Server Express по ссылке на UI.

Запускаем SQL Server Configuration Manager и включаем Pipe и TCP/IP протоколы. В настройках TCP/IP включаем все доступные IP адреса Enabled и для IPAll устанавливаем статический порт 1433.

В настройках Firewall`a разрешаем подключения на следующие порты:

• исходящие подключения на агент (порт 6910)
• входящие подключения к службе контроллера 6901
• входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
• подключения к студии (фреймворку LoadTest), исходящий порт 6915
• входящие подключения на TCP порт 1433 и UDP 1434

Возвращаемся в Test Controller Configuration Tools и нажмаем Apply settings. Начнется процесс конфигурирования контроллера тестирования. В последнем сообщении будет warning, на который не стоит обращать внимания.

При развертывании VM для агента в настройках открываем следующие порты:

• TCP порт 445 для удаленного сбора счетчиков производительности
• TCP порт для подключения к Test Agent`y 6910
• Remote Desktop

После настройки VM подключаемся к ней через RDP и устанавливаем TestAgent.

В настройках Firewall`a следует разрешить подключения на следующие порты:

• Входящие подключения к службе контроллера 6910
• Исходящие подключения к контроллеру тестирования 6901
• Входящие подключения к службе RPC для сбора счетчиков производительности – порт 445

Запускаем Test Agent Configuration Tools, в настройках указываем свой аккаунт и прописываем строку подключения к контроллеру. После нажатия Apply Settings запустится процесс конфигурирования агента тестирования.

После успешного его завершения отобразится окно статуса подключения агента

Перейдем к настройке виртуальной машины с Visual Studio .

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

После настройки VM подключаемся к ней по RDP и в настройках Firewall’a прописываем следующие подключения:

• Открываем порт 6915 для входящих соединений
• Открываем порт 6901 для исходящих на контроллер
• Исходящие порты UDP 1434 и TCP 1433 для подключения к базе SQL
• Исходящий 445 для подключения к RPC

Создаем новое решение Web performance And Load Test Project. Добавляем в него UnitTestProject1. В SolutionItems добавляем новый файл типа TestSettings и открываем его. На вкладке Roles устанавливаем RemoteExecution и прописываем вручную DNS имя виртуальной машины контроллера.

В меню Load Test выбераем вкладку Manage Test Controller и проверяем, что студия может подключиться к контроллеру:

Затем создаем новый Load Test, на вкладке Counter Sets добавляем для снятия метрик машину, на которой установлено тестируемое приложение и выбираем хотя бы один из доступных по умолчанию наборов счетчиков.

Внутри созданного нагрузочного теста добавим необходимые счетчики производительности для сервера приложения. Для этого два раза нажимаем на созданный нагрузочный тест, правой кнопкой мыши добавляем Add counters в созданном ранее Counter Set’e. Аналогичную процедуру проделаем с сервером БД.

После чего можно добавить созданный Counter Set в Counter Set Mapping, чтобы система собирала счетчики в процессе прохождения теста. Теперь тест можно запустить. Результаты тестирования каждого прогона теста будут сохраняться в автоматически созданную на контроллере базу LoadTest.

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

Цель первого прогона: определение максимального числа одновременно работающих пользователей при сохранении времен отклика в пределах значения х4 от единичного прогона (в данном случае 5 секунд)

Для определения максимального числа одновременно работающих пользователей были определены следующие параметры сценария нагрузки: нагрузка плавно подается на протяжении 10 часов для фиксированного числа пользователей, начиная со значения 500 пользователей и увеличивается каждые 30 минут на 500 пользователей до значения 10 000 одновременно работающих пользователей.

По итогам этого теста можно заключить, что по истечении 1 часа 30 минут приложение начинает деградировать. Сопоставив эти данные с графиком количества активных виртуальных пользователей, делаем вывод, что времена откликов начинают превышать значение 5 секунд при одновременной работе 1 500 пользователей. Однако на протяжении всего теста, продолжительностью 10 часов, не было зафиксировано таймаутов, что свидетельствует о возможности приложения выдерживать нагрузку до 10 000 одновременно работающих пользователей с увеличением времени отклика.

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

Мониторинг утилизации ресурсов позволяет сделать вывод, что имеет смысл пересмотреть конфигурацию сервера БД с целью снижения CPU, однако и текущая конфигурация обеспечивает одновременную бесперебойную работу 1 500 пользователей.

Средствами облачной службы Microsoft Azure было проведено нагрузочное тестирование интернет-магазина AdvantShop, так же развернутого в облаке. Приняв во внимание рекомендации по оптимизации работы приложения, коллеги из AdvantShop выпустят новую версию приложения. А благодаря тому, что инфраструктура нагрузочного тестирования была развернута в облаке, мы обеспечили себе возможность в любой момент повторить нагрузочные испытания с минимальным временем на подготовку и развертыванием стенда с новой конфигурацией – достаточно перенастроить и запустить VM облаке.

Наша команда столкнулась с недостатками инструментов нагрузочного тестирования, и, в конце концов, было решено разработать собственный сервис. Основные сложности:

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

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

Что уже сделано?

• Можно тестировать задания из списка url, до 20 штук
• Каждая url может содержать один или несколько случайных параметров, задаваемых с помощью функции $RND
• Тест запускается с множества серверов, на каждом из которых работает только 8 потоков
• Тестирование можно проводить из 5 регионов AWS - Дублин, Франкфурт, Восток/Запад США, Токио
• Тесты до 200 потоков мы готовы предоставлять бесплатно

Для теста открываем форму , где указываем email, заполняем URL, выбираем количество потоков тестирования, регион и начинаем тест.

*** UPDATE ***
Я вижу много смелых хабравчан ставит задание на 200 потоков. Если предположить, что 1 страница выдается за 1 секунду то это соответствует посещаемости >100К посетителей в час. Обычные проекты, в том числе наши, умирают от таких тестов.

Через минуту будет готов ваш результат (для примера посмотрите отличный результат - тестирование example.net). Как видим, 200 потоков позволяет генерировать более 1000 запросов в секунду - все зависит от скорости связи с тестируемым сервисом, и. собственно, скорости ответа.

Если вы готовы похвастаться вашим результатом на нашем сайте - можете нажать кнопку Public result. Для того, чтобы показать его своим коллегам достаточно отправить ссылку.

Что тестировать?
Статические ресурсы, картинки, скрипты должны отдаваться с CDN. Тестировать их скорость отдачи имхо не имеет смысла, нужно тестировать только общую скорость загрузки страницы, к примеру с помощью старого доброго http://tools.pingdom.com/fpt/

Loadme сосредотачивается на тестировании кода страниц / методов api и т.п… Тестировать nginx отдающий 1x1.gif с помощью этого инструмента конечно можно, но практической пользы нет, и nginx от этого даже не согреется.

Чтобы определиться, какие же страницы являются самым узким местом, лучше всего воспользоваться newrelic. В отличие от популярного google analytics он также позволяет отслеживать статистику запросов ботов, и строить запросы по количеству операций, приходящихся на ту или иную страницу, а также какая из страниц больше всего портила впечатление пользователей по индексу apdex .
Как известно, ложка дегтя бочку меда портит, и если ваше приложение будет тормозить на каких-то даже относительно редких действиях это вполне может влиять и на популярные легковесные операции.

Как работают редиректы?
Редиректы выполняются; мы их активно используем это для тестирования одного из наших сайтов wikiart.org, реализовав на нем функцию «перейти на случайную картину».

Почему важно тестировать несколько url?
Для тестирования взаимного влияния популярных быстрых страниц и медленных (к примеру, поиска)

Зачем нужен $RND?
Синтаксис - $RND(from,to).
К примеру, http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) будет генерировать произвольные запросы по поиску товаров по цене начиная от 0 до 1000 и заканчивая от 1000 до 10000. Это дает возможность оценить реальную мощность поиска.
К примеру, популярный украинский магазин Rozetka тратит в среднем 5 секунд на поиск смартфонов по случайной цене:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d , что является весьма далеким от идеала результатом.
Амазон справляется с этой задачей принципиально лучше - значительное количество ошибок в результате, скорее всего, является защитой от ddos

Дальнейшие планы

Post, put, delete запросы
Нужная штука, однозначно, есть в планах.

Авторизация
Достаточно ли будет поддержки куки, с тем чтобы первый запрос логинил тест под случайным пользователем (для чего понадобится поддержка со стороны сервера), и дальнейшая работа пойдет от имени этого пользователя?

Ступенчатые тесты
Скажем, провести серию тестов: 25%, 50%, 75% и 100%, и увидеть разницу в скорости.

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

Регулярный тест по расписанию
Повторять тест каждый день / неделю и высылать отчет на email.
Также можно предоставиьт какой-нибудь webhook для иницирования существующего теста из кода (к примеру, после обновления)

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

Подтверждение собственности домена
Ограничение не более 200 агентов на 1 домен существует ровно для того чтобы никто не поверг в ddos чужой сайт. Для своего сайта вы можете создать еще один поддомен и протестировать его еще раз.
В будущем, однако, нужно будет сделать подтверждение доменов с помощью CNAME записи или файла с определённым именем.

Существующие конкуренты

Loadimpact.com - для нормального нагрузочного теста, хотя бы 100 запросов в секунду, потребуется 1500 так называемых «виртуальных юзеров» - каждый из них загружает страницу 1 раз в 15 секунд. Стоит такой пакет на данный момент $299 в месяц.

Loader.io - отличный сервис, платный пакет всего $99 в месяц. Очень гибкие настройки URL - можно завать методы, куки, хедеры, но нам не хватило рандомизации теста.

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

Все идет по плану

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

• Нагрузочный (Load-testing) – определяется работоспособность системы
  при некоторой строго заданной заранее (планируемой, рабочей) нагрузке.
• Устойчивости (Stress) – применяется для проверки параметров системы
  в анормальных и экстремальных условиях, основная задача во время этого теста -
  попытаться нарушить работу системы. Позволяет определить минимально
  необходимые величины системных ресурсов для работы приложения, оценить
  предельные возможности системы и факторы, ограничивающие эти возможности.
  Также определяется способность системы к сохранению целостности данных при
  возникновении внештатных аварийных ситуаций.
• Производительности (Performance) – комплексная проверка, включающая
  предыдущие два теста, предназначена для оценки всех показателей системы.

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

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

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

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

Open Systems Testing Architecture

OpenSTA (www.opensta.org)
- больше чем приложение для тестов, это открытая архитектура, проектируемая
вокруг открытых стандартов. Проект создан в 2001 году группой компаний CYRANO ,
которая поддерживала коммерческую версию продукта, но CYRANO распался, и сейчас
OpenSTA распространяется как приложение с открытым кодом под лицензией
GNU GPL, работает в Windows NT 4.0SP5/2000/XP. Для работы требует Microsoft Data
Access Components (MDAC), который можно скачать сайта корпорации.

Текущий инструментарий позволяет провести нагрузочное испытание HTTP/HTTPS
сервисов, хотя его архитектура способна на большее. OpenSTA позволяет
создавать тестовые сценарии на специализированном языке SCL (Script Control
Language). Для упрощения создания и редактирования сценариев используется
специальный инструмент Script Modeler. Выбираем Tools – Canonicalize URL,
запустится веб-браузер. Просто ходим по сайту, собирая ссылки, которые будут
сохранены в скрипт. Все параметры запроса поддаются редактированию, возможна
подстановка переменных. Структура теста и заголовки будут выводиться во вкладках
в панели слева. Тесты удобно объединять в наборы. Настройки прокси задаются в
самом скрипте, поэтому можно указать несколько серверов. Реализована возможность
организации распределенного тестирования, что повышает реалистичность, или когда
с одного компьютера не получается нагрузить мощный сервер. Каждая из машин такой
системы может выполнять свою группу заданий, а repository host осуществляет сбор
и хранение результатов. После установки на каждой тестирующей системе
запускается сервер имен, работа которого обязательна. Поддерживается
аутентификация пользователей на веб-ресурсе и установление соединений по
протоколу SSL. Параметры работы нагружаемой системы можно контролировать с
помощью SNMP и средств Windows NT. Результаты тестирования, включающие время
откликов, количество переданных байт в секунду, коды ответа для каждого запроса
и количество ошибок выводятся в виде таблиц и графиков. Использование большого
числа фильтров позволяет отобрать необходимые результаты. Результат можно
экспортировать в CSV-файл. Возможности по выводу отчетов несколько ограничены,
но по ссылкам на сайте можно найти скрипты и плагины, упрощающие, в том числе,
анализ полученной информации.

Apache JMeter

Apache JMeter (jakarta.apache.org/jmeter)
является Java-приложением с открытым кодом, предназначен для нагрузочного
тестирования не только веб-приложений и их отдельных компонентов (скрипты,
сервлеты, Java объекты и др.), но также FTP-серверов, баз данных (с
использованием JDBC) и сети. Функциональность расширяется с помощью плагинов.
Поддерживается SSL (через Java Secure Sockets Extension). Возможно проведение
тестов как с использованием графического интерфейса, так и из командной строки.
Использование Java подразумевает кроссплатформенность, поэтому JMeter
уверенно работает в различных *nix-системах, в Windows от 98 и некоторых других
ОС. Распространяется под Apache License.

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

Для работы достаточно запустить ApacheJMeter.jar или в консоли jmeter.bat
(Windows) или jmeter.sh (*nix).

JMeter имеет встроенный прокси-сервер, который предназначен для записи
сессий, но можно использовать и внешний. Перед началом тестирования необходимо
составить тестовый план, описывающий серию заданий, которые необходимо выполнить
JMeter . Он должен содержать одну или несколько групп потоков (Thread
Groups) и другие элементы:

• Логические контроллеры (Logic controllers);
• Типовые контроллеры (Sample generating controllers);
• Слушатели (Listeners);
• Таймеры (Timers);
• Соответствия (Assertions);
• Конфигурационные элементы (Configuration elements).

Первым делом добавляем группу потоков (Edit - Add - Thread Group). В ее
настройках указываем название, количество запускаемых потоков, то есть
виртуальных пользователей (Number of threads), время задержки между запуском
потоков (Ramp-Up Period), количество циклов выполнения задания (Loop Count),
здесь же можно определить выполнение задания по расписанию (Sheduler). Далее,
щелкая в созданную группу, необходимо добавить образец запроса (Sampler), выбрав
его из списка. Для нагрузочного тестирования или проверки работоспособности
сервера достаточно выбрать HTTP Request (Add -Sampler - HTTP Request). Здесь
указываем название, IP-адрес и порт веб-сервера, протокол, метод передачи данных
(GET, POST), параметры переадресации, передачу файлов на сервер. Настраиваем и
жмем на Run. Вывод результата осуществляется с помощью Listeners, каждый
по-своему выводит результат. Например, Aggregate Graph выводит суммарные
результаты теста в виде таблицы и графика.

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

WAPT – Web Application Testing

WAPT (www.loadtestingtool.com)
позволяет испытать устойчивость веб-сайта и других приложений, использующих
веб-интерфейс, к реальным нагрузкам. Разрабатывается новосибирской компанией
SoftLogica LLC. Это одна из самых простых в использовании программ обзора. Для
проведения простого теста даже не нужно заглядывать в документацию, интерфейс
прост, но не локализован. Работает под управлением Windows от 98, поддерживается
и Vista. Для проверки WAPT может создавать множество виртуальных
пользователей, каждый с индивидуальными параметрами. Поддерживается несколько
видов аутентификации и куки. Сценарий позволяет изменять задержки между
запросами и динамически генерировать некоторые испытательные параметры,
максимально имитируя таким образом поведение реальных пользователей. В запрос
могут быть подставлены различные варианты HTTP-заголовка, в настройках можно
указать кодировку страниц. Параметры User-Agent, X-Forwarded-For, IP указываются
в настройках сценария. Значения параметров запроса могут быть рассчитаны
несколькими способами, в том числе, определены ответом сервера на предыдущий
запрос, используя переменные и функции. Поддерживается работа по защищенному
протоколу HTTPS (и все типы прокси-серверов). Созданные сценарии, сохраняемые в
файле XML-формата, можно использовать повторно. Кроме стандартных Performance и
Stress, в списке присутствуют несколько других тестов, позволяющих определить
максимальное количество пользователей и тестировать сервер под нагрузкой в
течение долгого периода.

Для проведения теста необходимо выбрать New – Scenario, в результате
запустится мастер создания теста. На первом шаге указывается тип теста и далее в
каждом окне заполняются параметры будущего теста. Здесь можно указать
фиксированное количество виртуальных пользователей, либо ступенчатое увеличение
с указанием минимального и максимального числа и временного интервала, выставить
таймер проведения теста. На следующем шаге задается время между кликами (think
time), скорость соединения, указывается диапазон IP-адресов, который будет
использован виртуальными пользователями. Нажатие на IP Adress List позволит
составить список таких адресов. Также выставляется HTTP-параметр User-Agent и
включается эмуляция прокси. Если требуется, чтобы виртуальные пользователи имели
индивидуальные настройки, на следующем шаге мастера для каждого из них
необходимо создать свой профиль, нажав New или загрузив сохраненный. В следующем
окне программы необходимо выставить параметры профилей.

После нажатия на кнопку Готово сценарий сохраняется. Теперь, чтобы указать на
объект тестирования, создаем профиль New – Profile и заполняем все параметры на
вкладках. Здесь же доступны для редактирования некоторые параметры, задаваемые
раннее с помощью мастера. Также указывается загрузка рисунков виртуальным
пользователем, параметры аутентификации, использование Cookies и другие.
На вкладке Recorder указываем адрес сайта, доступность которого можно тут же
проверить, нажав Go. Одновременно последует запрос на запуск Recorder, который
будет отслеживать посещенные страницы и записывать URI (они будут выводиться в
панели слева). Когда вся информация собрана, нажимаем Run Test. Подробные отчеты
в форме графика выводятся по ходу проведения теста, по окончании будет
сформирована HTML-страница. В результате можно получить информацию о времени
ответа сервера с возрастанием нагрузки, по количеству ошибок, переданных и
принятых байт и т.д.

NeoLoad

NeoLoad (www.neotys.com)
- еще одна система, позволяющая провести нагрузочное тестирование
веб-приложений. Написана на Java, работает на компьютерах, работающих под
управлением Windows NT/2000/XP, Linux и Solaris. В отчете можно получить
подробную информацию по каждому загруженному файлу. NeoLoad весьма удобен для
оценки работы отдельных компонентов (AJAX, PHP, ASP, CGI, Flash, апплетов и
пр.). Возможна установка времени задержки между запросами (thinktime) глобально
и индивидуально для каждой страницы. Тестирование проводится как с
использованием весьма удобной графической оболочки, так и с помощью командной
строки (используя заранее подготовленный XML-файл). Поддерживает работу с
протоколом HTTPS, с HTTP и HTTPS прокси, basic веб-аутентификацию и cookies,
автоматически определяя данные во время записи сценария, и затем проигрывает во
время теста. Для работы с различными профилями для регистрации пользователей
могут быть использованы переменные. При проведении теста можно задействовать
дополнительные мониторы (SNMP, WebLogic, WebSphere, RSTAT и Windows, Linux,
Solaris), позволяющие контролировать и параметры системы, на которой работает
веб-сервер.

При помощи NeoLoad можно проводить и распределенные тесты. Один из
компьютеров является контролером, на остальные устанавливаются генераторы
нагрузки (loadGenerator). Контролер распределяет нагрузку между loadGenerator и
собирает статистику.

Очень удобно реализована работа с виртуальными пользователями. Пользователи
имеют индивидуальные настройки, затем они объединяются в Populations (должна
быть создана как минимум одна Populations), в Populations можно задать общее
поведение (например, 40% пользователей популяции посещают динамические ресурсы,
20% читают новости). Виртуальные пользователи могут иметь индивидуальный
IP-адрес, полосу пропускания и свой сценарий теста.

Сценарий будущего теста создать очень просто. Запускаем приложение (при
первом запуске потребуется ввести регистрационный ключ, 30-дневная версия после
регистрации будет отправлена по почте), выбираем New Project, вводим название
проекта. После этого будет показана небольшая подсказка по поводу дальнейших
действий, нажатие Start Recording запустит веб-браузер, все перемещения будут
записаны. По окончании нажимаем Stop Recording или закрываем браузер.
Запускается мастер, который поможет создать виртуальных пользователей и
произведет автоматический поиск динамических параметров в записанных страницах,
выставит среднее значение thinktime. Компоненты страницы (HTML, images, CSS)
сохраняются отдельно. Для получения результата требуется пройти три шага:

• Design - настройка проекта, здесь три вкладки. В Repository указываются
  веб-страницы и параметры запросов, в Virtual User создаются виртуальные
  пользователи, указываются URL, которые они должны "посетить", и дополнительные
  условия из левой вкладки поля Actions. В Populations – задания каждой из групп
  пользователей. В Actions могут быть выбраны следующие действия: Delay
  (установка задержки), Loop (повтор запроса), While (цикл), If...Then...Else
  (условие), Container и Random Container (групповые действия), Try...Catch
  (обработка ошибок), Stop virtual user (останов работы виртуального
  пользователя).
• Runtime – указываются параметры теста, проводится тест. Здесь же в
  отдельных вкладках по ходу проведения теста выводится статистика.
• Results – отвечает за вывод различной статистики в виде таблиц и графиков.

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

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

Продукты от Microsoft

Корпорация Microsoft предлагает целых два продукта, позволяющих
протестировать веб-сервер под нагрузкой. Это Microsoft Application Stress
Tool и Web Capacity Analysis Tool . Первый распространяется как
отдельный продукт и имеет графический интерфейс. Второй входит в состав
комплекта инструментов Internet Information Services 6.0 Resource Kit Tools ,
работает из командной строки. MAST более наглядный, в создании теста
поможет простой мастер создания тестов, возможна работа с cookies, регулировка
нагрузки по разным URL. Сценарий тестирования может быть создан вручную или
записан с помощью веб-браузера и при необходимости отредактирован. В WAST
уровень нагрузки (stress level) регулируется путем задания количества нитей,
осуществляющих запросы к серверу, а число виртуальных пользователей
рассчитывается как произведение числа нитей на число сокетов, открытых каждой из
нитей. По окончании теста получаем простой отчет в текстовой форме, в котором
дана информация по числу обрабатываемых запросов в единицу времени, среднему
времени задержки, скорости передачи данных на сервер и с сервера, количеству
ошибок и т.д. Отчет можно экспортировать в CSV-файл. Никаких возможностей по
статистической обработке не предусмотрено, то есть с его помощью можно только
оценить работу при определенных условиях.

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

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

Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).

На втором этапе проводится нагрузочный тест (Load Test) , с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).

Как правильно подавать нагрузку на систему?

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

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

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

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

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

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

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

Задачей объемного теста (Volume Test) является оценка производительности системы при увеличении объемов данных, хранимых в базе данных приложения. Схема подачи нагрузки при данном виде теста такая же, как и при нагрузочном. Для проведения теста требуется база данных, заполненная необходимым объемом данных. Так, при тестировании биллинговой системы для оператора мобильной связи, объем данных был выбран исходя из ее прогнозируемого наполнения через два года после выхода обновленной версии системы в производство.

Тест на стабильность (Stability Test) позволяет оценить работоспособность системы при длительной ожидаемой нагрузке в режиме работы 24/7. К примеру, если веб-сайт посещают пользователи, находящиеся в разных часовых поясах, уровень нагрузки может сохраняться постоянным. Помимо возможных перезапусков серверов системы под продолжительной нагрузкой, при тесте на отказоустойчивость также изучается влияние редких событий на деградацию производительности системы, например, работа сборщиков мусора.

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

Тестирование клиентской части vs . тестирование производительности

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

Наилучшим решением проблем со стабильностью и сбоями в работе веб-серверов является обеспечение двухуровневой архитектуры приложения: клиентской, или Front - end , части и серверной, или Back - end , части.

Пользователь открывает браузер и отправляет запрос к странице сайта на Front - end сервер. Запрос принимается и запрашивается у исполнительной части веб-приложения – Back - end сервера, который хранит логику приложения, обеспечивает выполнение PHP-скриптов и генерирует HTML-страницы. Front-end принимает сформированную страницу от Back-end и в качестве ответа на запрос пользователя передает ее в браузер. Получив страницу, браузер пользователя начинает ее отображение, что сопровождается отправкой серии запросов на графический контент и CSS. Эти запросы принимает Front-end и обрабатывает без обращений к Back-end’у.

Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Front-end применяется тестирование клиентской части, или Client - Side Testing , а для Back-end – тестирование производительности серверной части .

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

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

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

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

Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.

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

Тестирование производительности серверной части направлено на анализ выполнения запросов и получения соответствующего запроса от Back-end.

Цели данного вида тестирования:

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

Нагрузочное тестирование

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

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

Нагрузочное тестирование программного обеспечения

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

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

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

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

Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется "Proof-of-Concept" тестированием.

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

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

1. Уникальность запросов

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

Иллюстрация различной дисперсии распределений для времени выполнения запросов X и Y.

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

2. Время отклика системы

В общем случае время отклика системы подчиняется функции нормального распределения .

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

3. Зависимость времени отклика системы от степени распределённости этой системы.

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

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

4. Разброс времени отклика системы

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

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

5. Точность воспроизведения профилей нагрузки

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

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

Инструментарий для тестирования производительности

Следует отметить, что для большинства видов тестирования производительности используется один и тот же инструментарий, умеющий выполнять типовые задачи.

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

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

• Приложение,
• База данных,
• Сеть,
• Обработка на клиентской стороне,
• Балансировка нагрузки.

Также следует отметить появление сетевых Business-to-business (B2B) приложений, использующих соглашение об уровне услуг (или SLA, Service Level Agreement). Нарастающая популярность B2B-приложений привела к тому, что всё больше приложений переходят на сервис-ориентированную архитектуру , в случае которой обмен информацией происходит без участия веб-браузеров. Примером такого взаимодействия может служить бюро туристических услуг, запрашивающее информацию об определённом авиарейсе между Санкт-Петербургом и Омском, в то время как авиакомпания обязана предоставить ответ в течение 5 секунд. Часто нарушение договора об SLA грозит крупным штрафом.

Наиболее популярные инструменты для нагрузочного тестирования представлены ниже.

ПО	Наименование производителя	Комментарии
OpenSTA	"Open System Testing Architecture"	Свободно распространяемое программное обеспечение для нагрузочного/стресс тестирования, лицензированное GNU GPL. Использует распределённую архитектуру приложений, основанную на CORBA . Доступна версия под Windows, хотя имеются проблемы с совместимостью с Windows Vista. Поддержка прекращена в 2007 году.
IBM Rational Performance Tester	IBM	Основанное на среде разработки Eclipse ПО, позволяющее создавать нагрузку больших объёмов и измерять время отклика для приложений с клиент-серверной архитектурой. Требует лицензирования.
JMeter	Открытый проект Apache Jakarta Project	Основанный на Java кроссплатформенный инструментарий, позволяющий производить нагрузочные тесты с использованием JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP соединений. Даёт возможность создавать большое количество запросов с разных компьютеров и контролировать процесс с одного из них.
HP LoadRunner	HP	Инструмент для нагрузочного тестирования, изначально разработанный для эмуляции работы большого количества параллельно работающих пользователей. Также может быть использован для unit- или интеграционного тестирования .
SilkPerformer	Micro Focus
Visual Studio Load Test	Microsoft	Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing
LoadComplete	SmartBear

Основные показатели (метрики) производительности

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

1. Потребление ресурсов центрального процессора (CPU, %)

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

2. Потребление оперативной памяти (Memory usage, Mb)

Метрика, показывающая количество памяти, использованной приложением. Использованная память может делиться на три категории:

• Virtual - объём виртуального адресного пространства, которое использует процессор. Этот объём не обязательно подразумевает, использование соответствующего дискового пространства или оперативной памяти. Виртуальное пространство конечно и процесс может быть ограничен в возможности загружать необходимые библиотеки.
• Private - объём адресного пространства, занятого процессором и не разделяемого с другими процессами.
• Working Set - набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы удаляются.

При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым «сборщиком мусора» (англ. Garbage Collector ). Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java - так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.

3. Потребление сетевых ресурсов

Эта метрика не связана непосредственно с производительностью приложения, однако её показатели могут указывать на пределы производительности системы в целом.

Пример 3: Серверное приложение обрабатывая запрос пользователя, возвращает ему видео-поток, используя сетевой канал в 2 мегабит. Требование гласит, что сервер должен обрабатывать 5 запросов пользователей одновременно. Нагрузочное тестирование показало, что эффективно сервер может предоставлять данные только 4 пользователям одновременно, так как мультимедиа-поток имеет битрейт в 500 килобит. Очевидно, что предоставление этого потока 5 пользователям одновременно невозможно в силу превышения пропускной способности сетевого канала, а значит, система не удовлетворяет заданным требованиям производительности, хотя при этом потребление ей ресурсов процессора и памяти может быть невысоким.

4. Работа с дисковой подсистемой (I/O Wait)

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

5. Время выполнения запроса (request response time, ms)

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

См. также

Ссылки

• Площадка услуг по тестированию сайтов и программного обеспечения (рус.)
• Портал специалистов по тестированию и обеспечению качества ПО (рус.) - Проект посвящён вопросам тестирования и повышения качества программного обеспечения.
• База знаний тестировщика (рус.) - Багтрекеры, автоматизированное тестирование, нагрузочное тестирование, юзабилити тестирование, сообщества, печатные издания, книги
• Автоматизация нагрузочного тестирования (рус.)
• Заметки по нагрузочному тестированию (рус.)

Литература

• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. - М .: «Вильямс», 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 экз. - ISBN 978-5-8459-1625-9

Wikimedia Foundation . 2010 .