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

Apache Bench

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

Ab -c 50 -n 10000 -f TLS1.2 -H "Accept-Encoding: gzip,deflate" https://somesite.com/

# Проверка максимального количества запросов с TLS

Команда выполнила 10 000 запросов в 50 потоков и, кроме всего прочего, показала скорость и обработанное количество запросов:

Total transferred: 59560000 bytes HTML transferred: 52160000 bytes Requests per second: 816.77 [#/sec] (mean) Time per request: 122.434 (mean) Time per request: 2.449 (mean, across all concurrent requests) Transfer rate: 2375.33 received

# Лог теста выдает намного больше информации

Из этого отчета самыми важными данными будут:

• Requests per second - количество запросов в секунду. К примеру если страница состоит из 20 частей (CSS, картинки и HTML), то в нашем примере сервер способен обработать около 40 одновременных пользователей в секунду.
• Time per request (mean) - среднее время на выполнение группы параллельных запросов (в нашем случае 50);
• Time per request (mean, across all concurrent requests) - среднее время на выполнение одного запроса.

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

Httperf

Этот тест с открытым исходным кодом был разработан в HP для измерения производительности веб-сервера. Инструмент не обновлялся несколько лет, но все еще является весьма актуальным.

Утилита, как и ab, проста в использовании и обладает достаточно широким функционалом. Запускается она так же просто, как и ab:

Httperf --hog --server 192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5

# Создание 100 000 сессий (по 5 вызовов через каждые 2 с) со скоростью 1000

А лог будет выглядеть так:

Total: connections 117557 requests 219121 replies 116697 test-duration 111.423 s Connection rate: 1055.0 conn/s (0.9 ms/conn, <=1022 concurrent connections) Connection time : min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1 Connection time : connect 31.1 Connection length : 1.000 Request rate: 1966.6 req/s (0.5 ms/req) Request size [B]: 91.0 Reply rate : min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples) Reply time : response 56.3 transfer 0.0 Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0) Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0 CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%) Net I/O: 467.5 KB/s (3.8*10^6 bps)

# Кроме всего прочего, производительность показывает величина скорости запросов (Request rate)

В этом отчете стоит сфокусироваться на:

• Connection rate - реальная скорость создания новых соединений. Она показывает способность сервера обрабатывать соединения, то есть в нашем случае до 1055 соед./с, но не более 1022 одновременных соединений.
• Connection time - время “жизни” успешных соединений между инициализацией и закрытием. Опять же показывает производительность сервера при обработке большого количества соединений.
• Request rate - скорость обработки запросов. То есть, количество запросов, которые сервер способен выполнять за секунду, показывает отзывчивость веб-приложения.

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

Tsung

Это мощная, продвинутая, мультизадачная и мультипоточная утилита. Инструмент может использоваться для нагрузки серверов HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP и Jabber/XMPP. Поддерживается SSL, мониторинг ресурсов системы и агенты SNMP, Munin или Erlang на удаленных серверах, симуляция поведения юзеров и расширенные отчеты.

Инструмент написан на Erlang, так что для начала необходимо установить нужные репозитории, а затем скачать и установить Tsung:

Wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz tar zxfv tsung-1.6.0.tar.gz cd tsung-1.6.0 ./configure && make && make install

# Распаковка и компиляция утилиты

Все настройки инструмента необходимо прописать в его файле конфигурации:

Cp /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml

# Копирование шаблона файла конфигурации в директорию Tsung

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

# Можно указывать дополнительные опции (к примеру браузеры юзеров), множества нодов для симуляции пользователей

Теперь можно запускать tsung:

Tsung -f tsung.xml start Starting Tsung "Log directory is: /root/.tsung/log/20160428-1117"

# Для запуска с множества нодов их нужно предварительно указать в настройках

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

Mkdir report_output cd report_output /usr/lib/tsung/bin/tsung_stats.pl --stats /root/.tsung/log/20160428-1117/tsung.log chromium graph.html

# Указывается предпочтительный браузер

Отчет будет состоять из графиков и важной дополнительной информации. В нем стоит обратить внимание на:

• Session - общее количество пользователей и количество одновременных сессий в секунду, которые веб-сервер обработал.
• Request - время отклика веб-сервера, его способность и скорость обработки одновременных запросов. К примеру 200 запросов/с значит, что в среднем 10 пользователей сможет одновременно получить зайти на веб-страницу, состоящую в общем из 20 компонентов (CSS, картинки и HTML). А это более 400 000 посетителей за 12 часов.
• Connect - время, требуемое на подключение, то есть отзывчивость веб-сервера .

Дополнительные графики позволят оценить нагрузку на веб-сервер за все время тестирования, отследить возникшие ошибки и динамику.

Другие утилиты

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

Самое главное

Apache Bench, Httperf и Tsung отлично подходят для тестирования нагрузки на большие и маленькие сайты. Но только tsung сможет выжать все соки из веб-сервера и показать на что он способен в условиях, приближенных к реальности. Не забывайте, что сначала все тесты нужно провести для одного пользователя, чтобы проследить зависимость и иметь точку отсчета.

Новое программное обеспечение и другие высокотехнологические продукты регулярно появляются на современном IT-рынке. Определить степень сопоставимости для решения конкретных задач, в каком объеме и достаточно ли безопасны в использовании возможно только в режиме нагруженного тестирования – услуги, которая предоставляется Компанией «Getbug Engineering ».

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

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

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

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

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

Цели нагрузочного тестирования :

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

Оборудование тестового стенда должно как можно ближе соответствовать промышленной конфигурации. Особенно если на основе полученных в результате тестирования времени выполнения операций будут приниматься бизнес решения. Если речь идет об оптимизации приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования необходимых утилит, например, MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS.

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

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

Тестирование производительности (Performance testing )

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

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

Тестирование стабильности (Stability / Reliability Testing )

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

Стрессовое тестирование (Stress Testing )

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

Объемное тестирование (Volume Testing )

Объемное тестирование позволяет оценить производительность при увеличении объемов данных в базе данных приложения:

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

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

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

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

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

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

Мы продолжаем рассказывать о компаниях-разработчиках решений (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 облаке.

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

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

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

• Нагрузочный (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-файл. Никаких возможностей по
статистической обработке не предусмотрено, то есть с его помощью можно только
оценить работу при определенных условиях.

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

Нагрузочное тестирование или тестирование производительности

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

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

Рассмотрим основные виды нагрузочного тестирования, также задачи стоящие перед ними.

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

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

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

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

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

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

Load vs Performance Testing

В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.