чем нагрузить сервер для тестирования
Открытые бенчмарки для нагрузочного тестирования серверов и веб-приложений
Это — подборка утилит, составленная на основе рекомендаций резидентов Hacker News и GitHub. В список вошли: Locust, Vegeta, Slow_cooker, k6 и Siege. Ими пользуются инженеры из DICE, EA и Buoyant, а также разработчики Kubernetes и Load Impact. Расскажем об этих инструментах.
Locust.io
Инструмент для нагрузочного тестирования сайтов. Все сценарии пишутся на Python. Специальный веб-интерфейс, построенный на Flask, позволяет мониторить результаты в реальном времени. Авторы Locust — швейцарские инженеры, среди которых числятся сотрудники компаний DICE и EA, занимающихся разработкой и изданием компьютерных игр.
В основу инструмента заложена интересная концепция: Locust («саранча») эмулирует поведение целого роя насекомых (виртуальных пользователей), «атакующих» сайт во время теста. Запросы формируют с помощью сетевой библиотеки для организации параллельных вычислений — gevent. Вот пример простого теста, который приведен на официальном сайте проекта:
Locust задействует библиотеку requests. Эта надстройка над стандартными средствами Python упрощает работу с HTTP и SSL и делает код более наглядным. К слову, документацию requests можно использовать в качестве шпаргалки для отладки тестов на Locust.
Этот инструмент для нагрузочного тестирования существует уже более семи лет. За это время вокруг него сформировалось обширное комьюнити — на GitHub более 10 тыс. звезд. Locust использовали при оценке работоспособности сети Battlelog для серии игр Battlefield. Об инструменте положительно отозвался Армин Ронахер (Armin Ronacher), автор фреймворка Flask.
Среди недостатков Locust выделяют довольно низкую производительность и периодические ошибки при оценке времени ответа сайтов. Также инструмент не умеет строить графики, но проблема решается выгрузкой результатов в виде CSV-файлов и отрисовкой графиков в редакторе таблиц.
Если вы хотите поближе познакомиться с Locust, то стоит обратить внимание на документацию инструмента. Также можно рекомендовать выступление Алексея Романова из Wargaming на Python Meetup. Он рассказывает, как писать сценарии, эмулирующие поведение пользователей.
Vegeta
Утилита командной строки для тестирования HTTP-сервисов, написанная на Go. Её можно подключить как библиотеку для создания своих инструментов нагрузочного тестирования. Разработчиком Vegeta выступил один из авторов отрытой платформы Sourcegraph — это движок для рецензирования и навигации по исходному коду, который используют в Lyft, Uber и Yelp.
Vegeta оценивает возможности сетевых ресурсов, «бомбардируя» их запросами с установленной частотой. Например, для проверки localhost достаточно прописать следующую команду:
По умолчанию Vegeta работает со стандартным потоком чтения команд (stdin), поэтому ресурс для тестирования передается через echo. Параметр duration указывает продолжительность теста. Репорт будет сгенерирован в файл results.bin. Отчеты Vegeta генерирует в текстовом формате, но при этом умеет рисовать графики. Сгенерировать их можно следующей командой:
Вокруг Vegeta сформировалось крупное сообщество — 12 тыс. звезд на GitHub. Инструмент даже использовали разработчики Kubernetes для оценки производительности своей платформы — тогда Vegeta генерировала около 10 млн запросов в секунду к кластеру из тысячи узлов.
Документация с описанием всех функций и флагов для тестов Vegeta есть в репозитории на GitHub. Там же можно найти предварительно скомпилированные исполняемые файлы.
Slow_cooker
Это — инструмент для нагрузочного тестирования серверов, написанный на Go. Его разработали инженеры из компании Buoyant, которая создает сервисную сеть для Kubernetes — Linkerd. Она является частью Cloud Native Computing Foundation и считается конкурентом Google Istio.
Фото — Joshua Aragon — Unsplash
Обычно утилиты для нагрузочного тестирования проверяют возможности сервера, направляя ему как можно больше запросов за короткое время. Авторы slow_cooker говорят, что их инструмент позволяет оценить работу железа под предсказуемой нагрузкой в течение длительного времени.
Специалисты из Buoyant используют свою разработку для тестирования Linkerd и других сервисов, например nginx. Инструмент довольно молодой — ему около трех — поэтому пока он не обзавелся большим комьюнити. Но в будущем ситуация может измениться, например, его репозиторий уже форкнули в Skysсanner, международном сервисе для поиска авиабилетов.
Исходный код вы можете найти на GitHub.
Инструмент для нагрузочного и регрессионного тестирования микросервисов, контейнеров и сайтов, размещенных в облаке. Он написан на Go и JavaScript разработчиками из Load Impact — это приложение для тестирования «стойкости» сайтов.
Работа с k6 строится по модели everything as code, когда логика тестов и все настройки пишутся на JavaScript. В скриптах отдельные шаги можно объединять в группы (group), что может быть удобно для тех, кто привык следовать принципам BDD. Вот пример такой группы:
Также инструмент дает возможность записывать скрипты и строить графики — последняя функция реализована на InfluxDB и Grafana. И у него есть интеграции с CI-системами вроде Jenkins, Circle CI, Team City и GitLab.
Пользователи говорят, что k6 не требователен к ресурсам, и у него удобный API. Но есть и несколько недостатков, в частности, k6 не поддерживает websocket и не умеет проводить тесты на распределенных системах. Хотя разработчики k6 в тематическом треде на Hacker News рассказали, что эти функции появятся в будущем.
Если вы хотите познакомиться с возможностями k6 самостоятельно, резиденты HN рекомендуют начать с технической документации — она подробная и с примерами. Если будут возникать какие-либо вопросы, можно обратиться на официальный форум.
Siege
Siege позволяет провести нагрузочное тестирование веб-серверов. Утилиту создал инженер Джефф Фалмер (Jeff Fulmer), чтобы разработчики могли проверить ресурсоемкость своего кода в условиях, приближенных к боевым. Siege эмулирует непрерывный поток обращений к сайту от множества пользователей, как бы удерживая сервер «под осадой» — отсюда и название инструмента.
После теста утилита показывает: время проверки, число транзакций за секунду, пропускную способность, количество удачных и неудачных запросов, а также их число с ответным кодом 200. Вот пример отчета, генерируемого Siege.
Siege получил довольно широкое распространение в ИТ-сообществе. Например, нагрузочному тестированию с его помощью посвящен целый раздел в книге «NGINX High Performance». Также его используют некоторые облачные провайдеры.
Из недостатков Siege можно выделить нестандартный синтаксис и неочевидные методы подсчета параметров тестирования — например, редиректы считаются успешными транзакциями, поэтому их количество может превышать общее число запросов. Если вы хотите опробовать Siege на практике, изучите онлайн-руководство — там разобраны некоторые «странности» системы.
Дополнительное чтение в блоге 1cloud.ru:
Что нового в Linux kernel 5.3 — графические драйверы, виртуализация и другие обновления
Почему разработчики мейнстрим-браузера снова отказались от отображения поддомена
Почему Apple изменила требования к разработчикам приложений
9 инструментов для теста производительности веб-сервера
Нагрузочное тестирование необходимо для того, чтобы веб-приложения знали емкость веб-сайта. Если вы хотите выбрать веб-сервер, то первое, что вы должны сделать, это выполнить нагрузочное тестирование производительности веб-сервера и посмотреть, какой из них вам подходит.
Бенчмаркинг может помочь вам принять решение:
Для тестирования я использовал веб-сервер Apache и Nginx. Ну а если вы не знаете какой веб-сервер вам выбрать, советуем прочитать про сравнение Nginx и Apache
1. ApacheBench
Apache
Давайте установим ApacheBench с помощью команды yum.
Если у вас уже есть httpd-tools, вы можете не устанавливать его.
Теперь давайте посмотрим, как он выполняет 5000 запросов с параллелизмом 500.
Итак, как вы можете видеть, Apache обработал 373 запроса в секунду, и общее количество запросов заняло 13,389 секунды.
Теперь вы знаете, что конфигурация по умолчанию может обслуживать эти многочисленные запросы, поэтому, когда вы вносите какие-либо изменения в конфигурацию, вы можете провести тест снова, чтобы сравнить результаты и выбрать лучший.
Nginx
Давайте сделаем тест, который мы сделали для Apache, чтобы вы могли сравнить, какой из них работает лучше.
ВАУ! Nginx обрабатывает 6593 запроса в секунду.
Таким образом, сравнивая два веб-сервера, вы поймете, какой из них выбрать для вашего веб-приложения.
Выше тест был сделан на CentOS 6,8, 64 бит. Вы можете попробовать несколько комбинаций ОС и версии веб-сервера для достижения оптимальных результатов.
2. SIEGE
Давайте запустим тест с 500 одновременными запросами в течение 5 секунд.
3. Gobench
Gobench написан на языке Go и представляет собой простую утилиту нагрузочного тестирования для оценки производительности веб-сервера. Он поддерживает более 20 000 одновременно работающих пользователей, чего нет у ApacheBench.
4. Apache JMeter
5. WRK
С помощью wrk запускать нагрузочный тест с несколькими потоками.
Давайте рассмотрим пример выполнения теста в течение 5 минут с 500 одновременными пользователями с 8 потоками.
6. HTTPLoad
Httpload может прочитать несколько URL-адресов из файла, или вы можете указать его в аргументе команды. Последняя версия поддерживает SSL / TLS, что означает, что вы можете запросить URL-адрес веб-страницы с поддержкой HTTPS (SSL).
При тестировании URL-адреса с поддержкой SSL у вас есть возможность указать шифр, и простая команда теста будет выглядеть следующим образом.
Чтобы лучше это понять, выше будет запущен тест против 200 одновременных пользователей в течение 2 минут.
7. Curl-loader
curl-loader написан на C для имитации загрузки приложения и поддерживает SSL / TLS. Наряду с тестированием веб-страницы, вы также можете использовать этот инструмент с открытым исходным кодом для загрузки FTP-серверов.
Вы можете создать план тестирования с сочетанием HTTP, HTTPS, FTP и FTPS в одной пакетной конфигурации.
8. httperf
Если вы ожидали число одновременных пользователей и хотите проверить, может ли ваш запрос обслуживать номер запроса, используйте следующую команду.
Приведенная выше команда будет проверять 100 запросов в секунду на 1000 HTTP-запросов.
9. Tsung
Заключение
Надеюсь, вышеупомянутые инструменты сравнительного анализа дадут вам представление о производительности вашего веб-сервера и помогут решить, что лучше всего подойдет для вашего проекта.
Под предельной нагрузкой: обзор программ нагрузочного тестирования веб-серверов
Содержание статьи
Сдавая веб-сервер в повседневную эксплуатацию, нужно быть уверенным, что он
выдержит планируемую нагрузку. Только создав условия, приближенные к боевым,
можно оценить, достаточна ли мощность системы, правильно ли настроены
приложения, участвующие в создании веб-контента, и прочие факторы, влияющие на
работу веб-сервера. В этой ситуации на помощь придут специальные инструменты,
которые помогут дать качественную и количественную оценку работы как
веб-узла в целом, так и отдельных его компонентов.
Все идет по плану
Прежде чем бросаться в бой, вначале следует разобраться, что мы хотим
получить в результате тестирования. Ведь проверка, как и любая другая работа,
требует предварительной подготовки. При неправильно сформулированной задаче
могут получиться результаты, которые будут не полностью отражать реальное
положение дел. Исходя из предполагаемой нагрузки веб-сервера, необходимо
определиться с критериями испытания. Установить, что будет считаться как успех,
а что как неприемлемая работа сервиса (например, время ответа, загрузка
сервера). Различают три варианта теста:
Во время тестирования имитируется одновременная работа нескольких сотен
или тысяч посетителей. Для большей правдивости каждый из виртуальных
пользователей может «ходить» по сайту по индивидуальному сценарию и иметь личные
параметры. Также в процессе тестирования можно имитировать кратковременные пики
нагрузки, когда количество посетителей скачкообразно увеличивается, что очень
актуально для сайтов с неравномерной аудиторией. Итак, чтобы полноценно провести
тестирование, необходимо знать:
Любой из этих параметров может повлиять на конечный результат. Необязательно
все проверки включать в один тест, можно разбить сначала задачу на подзадачи.
Например, проверка базовой системы (серверы: веб, приложений, базы данных) и
проверка отдельных модулей (сервлеты, скрипты и пр., например, проверка
аутентификации при большом количестве пользователей). В результате при
тестировании выдаются графики трех видов: линейный, нелинейный и насыщение. В
первом случае при возрастании нагрузки время отклика (т.е. обработки) остается
постоянным. При дальнейшем увеличении нагрузки время отклика также увеличивается
(почти линейно), и, наконец, наступает ситуация, подобная 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) и другие элементы:
Бесплатные продукты, увы, закончились, теперь парочка коммерческих решений.
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)
сохраняются отдельно. Для получения результата требуется пройти три шага:
Причем кроме общих значений, с помощью системы фильтров можно отобрать
информацию по любому параметру. При желании проект сохраняется для повторного
использования. Среди представленных продуктов возможность сравнения результатов
теста есть только у 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-файл. Никаких возможностей по
статистической обработке не предусмотрено, то есть с его помощью можно только
оценить работу при определенных условиях.