Выдержит ли нагрузку ваш веб-сервер?

 СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Выдержит ли нагрузку ваш веб-сервер?

Обзор программ для стресс-тестирования

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

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

Построение плана тестирования

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

Различают три варианта тестирования:

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

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

Чтобы полноценно провести тестирование, необходимо знать:

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

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

Теперь, когда план действий готов, переходим к рассмотрению утилит, которые помогут его воплотить.

WAPT 4.0

Одна из самых простых в использовании и в то же время функциональных программ обзора. Для проведения простого теста даже не потребовалось заглядывать в документацию, интерфейс прост и понятен, хотя и не локализован. Как вариант можно использовать командную строку. Работает под управлением MS Windows 98/Me/2000/XP/2003. WAPT позволяет испытать устойчивость веб-сайта и других приложений, использующих веб-интерфейс, к реальным нагрузкам. Разрабатывается новосибирской компанией SoftLogica LLC. Для проверки WAPT может создавать множество виртуальных пользователей в одном сценарии, каждый из них может иметь индивидуальный IP-адрес, идентификационные параметры, скорость соединения. Поддерживаются Windows (NTLM), базовая аутентификация и постоянные и сессионные (persistent и session) cookies. Сценарий позволяет изменять задержки между запросами и динамически генерировать некоторые испытательные параметры, максимально имитируя, таким образом, поведение реальных пользователей. В запрос могут быть подставлены различные варианты http-заголовка, в настроках возможно указать кодировку страниц. Параметры (как статические, так и маска) User-Agent, X-Forwarded-For, IP address, указываются в настройках сценария. Значения параметров запроса могут быть рассчитаны несколькими способами, в том числе определены ответом сервера на предыдущий запрос, в том числе используя некоторые локальные переменные и функции. Сценарий поведения каждого виртуального пользователя включает три регулируемых стадии: начальную (Initial), основную (Mail) и заключительную (Final). Поддерживается работа по защищенному протоколу HTTPS (SSL/TLS) (версии SSL 2.0/3.0) и все типы прокси-серверов (HTTP, HTTPS, SOCKS4, SOCKS5). Созданные сценарии, сохраняемые в файле XML-формата, можно использовать повторно. Кроме стандартных Performance и Stress, в списке присутствуют:

• Smoke – краткий тест, предназначенный для определения готовности приложения к работе вообще, например, есть ли смысл тестировать дальше, если сервер думает минуту.
• Capacity – тест для определения максимального количества посетителей;
• Endurance – тестирование под средней нагрузкой, в течение долгого периода времени.

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

Рисунок 1. Выбор типа теста в WAPT

После нажатия на кнопку «Готово» сценарий сохраняется. Это мы подготовили параметры теста. Для указания объекта тестирования необходимо создать профиль «New –> Profile» и заполнить все параметры на обеих вкладках (см. рис.2). Здесь же опять, только уже индивидуально, доступны для редактирования некоторые параметры, задаваемые раннее с помощью мастера. Также указывается загрузка рисунков виртуальным пользователем, параметры аутентификации, использование Cookies и другие.

Рисунок 2. Создание профиля будущего теста

На вкладке «Recorder» указываем адрес сайта, доступность которого можно тут же проверить, нажав «Go». Одновременно последует запрос на запуск Recorder, который будет отслеживать посещенные страницы и записывать URL (они будут выводиться в панели слева). И когда вся информация собрана, нажимаем «Run Test». Подробные отчеты в форме графика выводятся по ходу проведения теста, по окончании будет сформирована и html-страница. В результате можно получить информацию по времени ответа сервера с возрастанием нагрузки, количеству переданных и принятых байт, как в общем, так и в расчете на одного пользователя, количестве ошибок.

Рисунок 3. Проводим тест

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

OpenSTA

Open Systems Testing Architecture – это больше чем приложение для тестирования, это открытая архитектура, проектируемая вокруг открытых стандартов, в частности CORBA. Проект создан в 2001 году группой компаний CYRANO, которая поддерживала коммерческую версию продукта, но CYRANO распалась, и статус OpenSTA находится в подвешенном состоянии, так как на наследие CYRANO претендует несколько компаний.

В настоящее время OpenSTA распространяется как приложение, с открытым кодом под лицензией GNU GPL, работает в Windows NT 4.0SP5/2000/XP. Текущий инструментарий позволяет провести нагрузочное испытание http/https-сервисов, хотя его архитектура способна на большее. OpenSTA позволяет создавать тестовые сценарии на специализированном языке SCL (Script Control Language).

Для упрощения создания и редактирования сценариев используется специальный инструмент Script Modeler (см. рис.4). После его запуска необходимо выбрать «Tools –> Canonicalize URL», далее запустится веб-браузер, и все посещенные URL будут сохранены в скрипт. Все параметры запроса поддаются редактированию (скрипт, кстати, сам по себе интересен для понимания работы http), возможна подстановка переменных. Структура теста, заголовки, html будет выводиться во вкладках в панели слева. Тесты удобно объединять в  наборы. Настройки прокси задаются в самом скрипте, поэтому при выполнении задания можно использовать несколько прокси. Реализована возможность организации распределенного тестирования, что повышает реалистичность тестов и может понадобиться в том случае, когда с одного компьютера не получается полностью нагрузить мощный сервер. Каждая из машин такой системы может выполнять свою группу заданий. В этом случае одна из машин (repository host) осуществляет сбор и хранение результатов. После установки на каждой тестирующей системе запускается сервер имен OpenSTA name server, работа которого обязательна. Поддерживается аутентификация пользователей и установление соединений по протоколу SSL. Параметры работы нагружаемой системы во время проведения теста можно контролировать с помощью SNMP и средств Windows NT. Для этого достаточно выбрать «Collector –> New Collector» и указать источник. Результаты тестирования, включающие времена откликов, количество переданных в секунду байт, коды ответа для каждого запроса, количество ошибок, выводятся в виде таблиц и графиков (см. рис. 5). Использование фильтров (время теста, время ответа сервера, код ответа, размер, виртуальный пользователь или адрес, URL) позволяет отобрать необходимые результаты. Возможен экспорт результата в CSV-файл (например, для последующей обработки в Excel). OpenSTA мощный инструмент, обладающий всеми необходимыми функциями, но требующий некоторой подготовки как самого тестирующего, так и дополнительных временных затрат при проведении конкретного теста. К тому же возможности по выводу отчетов его несколько ограничены. В Интернете можно найти скрипты и плагины [1, 2], помогающие при анализе информации. Например, BView, доступный на домашнем сайте проекта, помогает отлаживать сценарии.

Рисунок 4. Окно Script Modeler

Рисунок 5. Результаты теста OpenSTA

Microsoft Web Application Stress Tool

Бесплатный продукт компании Microsoft, работающий только в среде Windows и предназначенный для стресс-тестов веб-сервисов. Имеется и более современная и также бесплатная разработка Web Capacity Analysis Tool, представляющая собой комплексный продукт для работы с IIS, предназначенная в том числе и для тестов производительности. Сценарий тестирования может быть создан вручную или записан с помощью веб-браузера и затем отредактирован. После выбора варианта создания сценария (см. рис. 6) запускается простой мастер, который поможет сохранить параметры. Для каждого запроса фиксируется запрашиваемый URL, время между запросами (delay), cookies и заголовки. После записи скрипта в «Setting» выставляется уровень нагрузки (stress level), который регулируется путем задания количества нитей, осуществляющих запросы к серверу. Параметром «stress multiplier» задается число сокетов на нить. Число виртуальных пользователей в Web Application Stress Tool рассчитывается как произведение числа нитей на число сокетов, открытых каждой из нитей. Далее задается общее время теста, задержки между запросами (может быть использовано случайное число), ширина полосы и прочие параметры. Создание максимальной нагрузки осуществляется путем задания нулевого интервала ожидания между запросами.

Рисунок 6. Создание сценария тестирования

Рисунок 7. Отчет Web Application Stress Tool

По окончании теста выводится отчет в текстовой форме (см. рис. 7), в котором можно получить информацию по следующим вопросам:

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

Отчет можно экспортировать в CSV-файл. Никаких возможностей по статистической обработке не предусмотрено, то есть с его помощью можно только оценить работу при определенных условиях. Среди возможностей Web Application Stress Tool:

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

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

Apache JMeter

Apache JMeter представляет собой Java-приложение с открытым кодом, предназначенное для нагрузочного тестирования не только веб-приложений и их отдельных компонентов (скрипты, сервлеты, Java-объекты и др.), но также FTP-серверов, баз данных (с использованием драйвера JDBC) и сети. Функциональность расширяется с помощью плагинов. Поддержка SSL возможна при наличии библиотеки JSSE (Java Secure Sockets Extension), которая входит в стандартную поставку JDK1.4 и выше. Возможна работа как с использованием графического интерфейса, так и в командной строке. Предусмотрены механизмы авторизации виртуальных пользователей, поддерживаются пользовательские сеансы, шаблоны, кэширование и последующий offline-анализ результатов теста, функции позволяют сформировать следующий запрос, основываясь на информации ответа на предыдущий. При наличии пакета JavaMail отчеты по проведенному тесту могут быть отправлены по электронной почте. Так же как и OpenSTA, JMeter позволяет проводить распределенные тесты. В этом случае один из компьютеров является сервером (bin/jmeter-server.bat), который управляет клиентами и собирает итоговую информацию.

Использование Java подразумевает кроссплатформенность, JMeter нормально работает в UNIX (Solaris, Linux и пр.), Windows 98/NT/2000/XP и OpenVMS Alpha 7.3+.

Для работы достаточно запустить в консоли файл jmeter.bat (Windows) или jmeter (UNIX).

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

$ bin/jmeter -H proxy.server -P 8000 -u username -a password

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

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

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

Рисунок 8. Настройка Thread Groups в Apache JMeter

Рисунок 9. Вывод результата Aggregate Graph

Инструмент тестирования NeoLoad

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

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

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

Рисунок 10. Подсказка в NeoLoad

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

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

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

Рисунок 11. Вывод результата теста в NeoLoad

Вывод

Тесты, как правило, проводятся не один раз, и после устранения недостатков хотелось бы сравнить результат с предыдущим. К сожалению, среди представленных продуктов такая возможность есть только у NeoLoad. Еще один подобный инструмент Web Performance Suite [3], также позволяет сравнить результаты тестов, в обзор не попал потому, что не удалось провести полноценный тест (вероятно, из-за ограничений trial-версии). Также следует обратить внимание на LoadRuner, 10-дневную тестовую версию которого размером в 300 Мб можно скачать с сайта проекта [4]. Используя утилиты нагрузочного тестирования, вы сможете получить информацию о работе веб-сервиса и, приняв необходимые меры по устранению выявленных недостатков, гарантировать требуемую производительность.

Сводная таблица

1. Скрипты к OpenSTA – http://www.trickytools.com/php/opensta.php
2. Документ «Analyzing OpenSTA Performance Results» – http://www.goldb.org/docs/opensta_log_analysis.pdf.
3. Сайт проекта Web Performance Suite – http://www.webperformanceinc.com.
4. Сайт проекта LoadRuner – http://www.mercury.com/us/products/performance-center/loadrunner.

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