Как оценить латентность HTTP с помощью wrk в Ubuntu 14.04

Вступление

Эта статья посвящена инструменту сравнительного анализа HTTP с открытым исходным кодом под названием wrk, который измеряет * задержку * ваших * HTTP * сервисов при * высоких нагрузках *.

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

wrk полезен для тестирования любого веб-сайта или приложения, использующего HTTP, таких как:

Rails и другие приложения на Ruby
Express и другие приложения JavaScript
PHP-приложения
Статические сайты, работающие на веб-серверах
Сайты и приложения для балансировщиков нагрузки, такие как Nginx
Ваш слой кэширования

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

wrk является открытым исходным кодом и может быть найден на GitHub.

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

Бенчмаркинг запросов с печеньем
Пользовательская отчетность
Сравнительный анализ нескольких URL-адресов - то, что популярный http://httpd.apache.org/docs/2.2/programs/ab.html [+ ab +], инструмент тестирования Apache HTTP-сервера, не может

Предпосылки

Инфраструктура, которую мы будем использовать в этом уроке, представлена на диаграмме ниже:

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/wrk-application-overview.png [Обзор инфраструктуры]

Как видите, мы будем использовать wrk в очень простом сценарии. Мы будем тестировать приложение Express в Node.js.

Мы раскрутим * две капли *: одну для wrk, которая генерирует нагрузку, а другую для приложения. Если бы они были в одной коробке, они бы конкурировали за ресурсы, и наши результаты не были бы надежными.

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

Раскрути две капли в * одном регионе *, так как они будут общаться по частному IP
Вызовите одну каплю * wrk1 *, а другую * app1 *, чтобы следовать этому уроку.
Выберите * 2 ГБ * памяти
Выберите * Ubuntu 14.04 *
Выберите * Частная сеть * в разделе * Доступные настройки *
Создайте sudo пользователя на каждом сервере

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

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/do-setup-infrastructure-with-notes.png [Предварительный просмотр настройки инфраструктуры цифрового океана]

Если вам нужна помощь в настройке Droplets, обратитесь к ths this статье.

Шаг 1 - Оба сервера: установите Docker

Чтобы сделать нашу жизнь проще, мы будем использовать Docker, чтобы мы могли запустить wrk и наше приложение внутри контейнеров. Это позволяет нам пропустить настройку среды Node.js, модулей npm и пакетов deb; все, что нам нужно, это загрузить и запустить соответствующий контейнер. Сэкономленное время будет потрачено на обучение.

Если вы не знакомы с Docker, вы можете прочитать введение к нему here.

Примечание: * Команды в этом разделе должны выполняться на * обеих каплях *.

Чтобы установить Docker, войдите на свои серверы и выполните следующие команды. Сначала обновите списки пакетов:

sudo apt-get update

Установите Wget и cURL:

sudo apt-get install -y wget curl

Загрузите и установите Docker:

sudo wget -qO- https://get.docker.com/ | sh

Добавьте вашего пользователя в группу + docker +, чтобы вы могли выполнять команды Docker без sudo:

sudo gpasswd -a ${USER} docker
sudo service docker restart
newgrp docker

Чтобы убедиться, что + docker установлен правильно, используйте эту команду:

docker --version

Вы должны получить следующий или похожий вывод:

OutputDocker version 1.7.1, build 786b29d

Шаг 2 - Подготовьте тестовое приложение

Выполните эти команды на * app1 * Droplet.

В целях тестирования автор опубликовал Docker image в общедоступном реестре Docker. Он содержит приложение для отладки HTTP, написанное на Node.js. Это не зверь производительности (сегодня мы не побьём рекорды), но этого достаточно для тестирования и отладки. Вы можете проверить исходный код here.

Конечно, в реальном сценарии вы захотите протестировать свое собственное приложение.

Прежде чем мы запустим приложение, давайте сохраним частный IP-адрес Droplet в переменную с именем + APP1_PRIVATE_IP +:

export APP1_PRIVATE_IP=$(sudo ifconfig eth1 | egrep -o "inet addr:[^ ]*" | awk -F ":" '{print $2}')

Вы можете просмотреть частный IP с:

echo $APP1_PRIVATE_IP

Выход:

Output

Ваш частный IP-адрес будет другим, поэтому запишите его.

Вы также можете получить частный IP-адрес с панели управления digitalocean.com. Просто выберите свою каплю и перейдите в раздел * Настройки *, как показано на рисунке ниже:

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/do-get-private-ip-with-notes.png [Digital Ocean находит частный IP-адрес Droplet]

Теперь запустите приложение, просто выполнив эту команду:

docker run -d -p $APP1_PRIVATE_IP:3000:3000 --name=http-debugging-application czerasz/http-debugger

Приведенная выше команда сначала загрузит требуемый образ Docker, а затем запустит контейнер Docker. Контейнер запускается в режиме detached, что означает, что он будет работать в фоновом режиме. Опция + -p $ APP1_PRIVATE_IP: 3000: 3000 + будет проксировать весь трафик к локальному контейнеру и из него на порт + 3000 +, а также к и с частного IP-адреса хоста на порт + 3000 +.

Диаграмма ниже описывает эту ситуацию:

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/debugging-application-container-overview.png [Визуализация контейнера отладочного приложения]

Теперь проверьте с помощью + curl +, чтобы увидеть, запущено ли приложение:

curl -i -XPOST http://$APP1_PRIVATE_IP:3000/test -d 'test=true'

Ожидаемый результат:

OutputHTTP/1.1 200 OK
X-Powered-By: Express
X-Debug: true
Content-Type: text/html; charset=utf-8
Content-Length: 2
ETag: W/"2-79dcdd47"
Date: Wed, 13 May 2015 16:25:37 GMT
Connection: keep-alive

ok

Приложение очень простое и возвращает просто сообщение + ok +. Поэтому каждый раз, когда wrk запрашивает это приложение, оно получает небольшое сообщение + ok +.

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

Просмотрите журналы приложений с помощью следующей команды:

docker logs -f --tail=20 http-debugging-application

Ваш пример вывода должен выглядеть следующим образом:

Output[2015-05-13 16:25:37] Request 1

POST/1.1 /test on :::3000

Headers:
- user-agent: curl/7.38.0
- host: 0.0.0.0:32769
- accept: */*
- content-length: 9
- content-type: application/x-www-form-urlencoded

No cookies

Body:
test=true

Если хотите, вы можете оставить это включенным во время выполнения тестов. Выйдите из хвоста с помощью + CTRL-C +.

Шаг 3 - Установите wrk

Войдите на сервер * wrk1 * и будьте готовы к установке wrk.

Поскольку у нас есть Docker, это очень просто. Просто загрузите изображение https://registry.hub.docker.com/u/williamyeh/wrk/ [+ williamyeh / wrk +] из реестра Docker с помощью этой команды:

docker pull williamyeh/wrk

Команда выше загружает образ Docker, который содержит wrk. Нам не нужно ни собирать wrk, ни устанавливать какие-либо дополнительные пакеты. Для запуска wrk (внутри контейнера) нам нужно только запустить контейнер на основе этого изображения, что мы и сделаем в ближайшее время.

Загрузка должна занять всего несколько секунд, потому что изображение очень маленькое - менее 3 МБ. Если вы хотите установить wrk непосредственно в свой любимый дистрибутив Linux, посетите this wiki page и следуйте инструкциям.

Мы также установим переменную + APP1_PRIVATE_IP + на этом сервере. Нам нужен частный IP-адрес из * app1 * Droplet.

Экспортируйте переменную с помощью:

export APP1_PRIVATE_IP=

Не забудьте изменить IP-адрес ++ на частный IP-адрес вашего * app1 * Droplet. Эта переменная будет сохранена только в текущем сеансе, поэтому не забудьте переустановить ее при следующем входе в систему для использования wrk.

Шаг 4 - Запустите WRK Benchmark Test

В этом разделе мы наконец увидим работу в действии.

Все команды в этом разделе должны быть выполнены на * wrk1 * Droplet.

Давайте посмотрим варианты, доступные для нас. Запуск контейнера wrk только с флагом + - version + выведет краткое описание его использования:

docker run --rm williamyeh/wrk --version

Выход:

Outputwrk 4.0.0 [epoll] Copyright (C) 2012 Will Glozer
Usage: wrk <options> <url>
 Options:
   -c, --connections <N>  Connections to keep open
   -d, --duration    <T>  Duration of test
   -t, --threads     <N>  Number of threads to use

   -s, --script      <S>  Load Lua script file
   -H, --header      <H>  Add header to request
       --latency          Print latency statistics
       --timeout     <T>  Socket/request timeout
   -v, --version          Print version details

 Numeric arguments may include a SI unit (1k, 1M, 1G)
 Time arguments may include a time unit (2s, 2m, 2h)

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

Простейший случай, который мы могли бы запустить с помощью wrk:

wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/

Что значит:

+ -t2 +: использовать * два * отдельных * потока *
+ -c5 +: открыть * шесть соединений * (первый клиент равен нулю)
+ -d5s +: запустить тест на * пять секунд *
+ -H 'Host: example.com' +: передать заголовок + Host + * * *
+ - тайм-аут 2 с +: определить * двухсекундный тайм-аут *
+ http: // $ APP1_PRIVATE_IP: 3000 / + Целевое приложение прослушивает + $ APP1_PRIVATE_IP: 3000 +
Оцените путь + / + нашего приложения

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

На рисунке ниже показана эта ситуация:

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/wrk-architecture-structure.png [структура архитектуры wrk]

Вот фактическая команда для теста: *

Давайте запустим описанный сценарий в нашем контейнере wrk Docker:

docker run --rm williamyeh/wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/

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

Шаг 5 - Оцените вывод

Выход:

OutputRunning 5s test @ http://10.135.232.163:3000
 2 threads and 5 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     3.82ms    2.64ms  26.68ms   85.81%
   Req/Sec   550.90    202.40     0.98k    68.00%
 5494 requests in 5.01s, 1.05MB read
Requests/sec:   1096.54
Transfer/sec:    215.24KB

Сводка текущей конфигурации:
```
Running 5s test @ http://10.135.232.163:3000
 2 threads and 5 connections
```
+ Здесь мы можем увидеть краткое описание нашей конфигурации. Тестирование заняло 5 секунд, IP-адрес тестируемого компьютера - «+ 10.135.232.163 +», и в тесте использовались два потока.
Параметры нормального распределения для статистики задержек и запросов / сек:
```
Thread Stats   Avg      Stdev     Max   +/- Stdev
 Latency     3.82ms    2.64ms  26.68ms   85.81%
 Req/Sec   550.90    202.40     0.98k    68.00%
```
+ Эта часть показывает нам обычные детали распределения для нашего теста - какие параметры будет иметь функция Gaussian. + Тесты не всегда имеют нормальное распределение, и поэтому эти результаты могут вводить в заблуждение. Поэтому всегда смотрите на значения * Max * и * + / - Stdev *. Если эти значения высоки, то вы можете ожидать, что ваш дистрибутив может иметь тяжелый хвост.
Статистика по номерам запросов, переданным данным и пропускной способности:
```
 5494 requests in 5.01s, 1.05MB read
Requests/sec:   1096.54
Transfer/sec:    215.24KB
```
+ Здесь мы видим, что за время «+ 5,01 » секунд wrk может выполнить « 5494 » запросов и передать « 1,05 МБ » данных. В сочетании с простой математикой (« общее количество запросов / продолжительность теста») мы получаем результат «+ 1096,54 +» запросов в секунду.

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

Какие результаты являются лучшими? *

Ваша цель состоит в том, чтобы + Requests / sec + как можно выше, а + Latency + - как можно ниже.

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

Теперь вы, вероятно, спросите себя: является ли +550,90 запросов / сек + с задержкой + 3,82 мс + хорошим результатом? К сожалению, нет простого ответа. Это зависит от многих факторов, таких как:

Количество клиентов, как мы уже говорили
Ресурсы сервера - это большой или маленький экземпляр?
Количество машин, которые обслуживают приложения
Тип вашего сервиса - это кеш, который обслуживает статические файлы, или рекламный сервер, который обслуживает динамические ответы?
Тип базы данных, размер кластера базы данных, тип подключения к базе данных
Тип запроса и ответа - это небольшой AJAX-запрос или толстый вызов API?
И много других

Шаг 6 - Примите меры для улучшения задержки

Если вы не удовлетворены качеством обслуживания, вы можете:

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

Для более подробного обсуждения улучшений приложений, посетите https://www.digitalocean.com/community/tutorials/5-ways-to-improve-your-production-web-application-server-setup[5 Пути улучшения вашего Настройка сервера производственного веб-приложения.

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

Вот и все, вы могли бы подумать, если бы не было этого Lua …

Имитация расширенных HTTP-запросов с помощью скриптов Lua

Поскольку wrk имеет встроенный LuaJIT (Just-In-Time Compiler для Lua), его можно расширить с помощью сценариев Lua. Как уже упоминалось во введении, это добавляет много функциональности для работы.

Использовать скрипт Lua с wrk просто. Просто добавьте путь к файлу к флагу + -s +.

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

Части скрипта Lua для WRK

В общем виде, используя скрипт с именем + test.lua +, вся команда может выглядеть так:

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/test.lua http://$APP1_PRIVATE_IP:3000

Мы объяснили команду wrk и ее параметры на предыдущем шаге. Эта команда не добавляет слишком много; только путь к сценарию и некоторые дополнительные команды, чтобы сообщить Docker, как найти его вне контейнера.

Флаг + - rm + автоматически удалит контейнер после его остановки.

Но мы действительно знаем, как написать скрипт Lua? Не бойся; Вы узнаете это с легкостью. Здесь мы рассмотрим простой пример, и вы сможете запускать свои собственные более сложные сценарии самостоятельно.

Сначала поговорим о предопределенной структуре скрипта, которая отражает внутреннюю логику wrk. Диаграмма ниже иллюстрирует это для одного потока:

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle.png [цикл сценариев Lua wrk]

WRK выполняет следующие этапы выполнения:

* Разрешить * IP-адрес домена
Начните с темы * setup *
Выполните фазу * стресс-тестирования *, которая называется фазой * бега *
Последний шаг называется просто «сделано»

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

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle-threads.png [цикл сценариев Lua для двух потоков]

Кроме того, * рабочая фаза * может быть разделена на три этапа: * init *, * request * и * response *.

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle-running-phase.png [цикл сценариев Lua wrk - рабочая фаза]

В соответствии с представленными диаграммами и documentation мы можем использовать следующие методы внутри скрипта Lua:

+ setup (thread) +: выполняется, когда все потоки были инициализированы, но еще не запущены. Используется для передачи данных в потоки
+ init (args) +: вызывается при инициализации каждого потока + Эта функция получает дополнительные аргументы командной строки для скрипта, которые должны быть отделены от аргументов wrk с помощью + - +. + Пример:

wrk -c3 -d1s -t2 -s /scripts/debug.lua http://$APP1_PRIVATE_IP:3000 -- debug true

+ request () +: необходимо возвращать объект HTTP для каждого запроса. В этой функции мы можем изменить метод, заголовки, путь и тело + Используйте вспомогательную функцию + work.format для формирования объекта запроса. + Пример:

return wrk.format(method, path, headers, body)

+ response (status, headers, body) +: вызывается при возврате ответа
+ done (сводка, задержка, запросы) +: выполняется после завершения всех запросов и вычисления статистики + Внутри этой функции доступны следующие свойства:

Property

Description

summary.duration

run duration in microseconds

summary.requests

total completed requests

summary.bytes

total bytes received

summary.errors.connect

total socket connection errors

summary.errors.read

total socket read errors

summary.errors.write

total socket write errors

summary.errors.status

total HTTP status codes > 399

summary.errors.timeout

total request timeouts

latency.min

minimum latency value reached during test

latency.max

maximum latency value reached during test

latency.mean

average latency value reached during test

latency.stdev

latency standard deviation

latency:percentile(99.0)

99th percentile value

latency[i]

raw latency data of request i

Каждый поток имеет свой собственный контекст Lua и свои локальные переменные.

Теперь мы рассмотрим несколько практических примеров, но вы можете найти еще много полезных сценариев для тестирования производительности в https://github.com/wg/wrk/tree/master/scripts [+ scripts + каталог] проекта wrk.

Пример: `+ POST +` запросы

Давайте начнем с самого простого примера, где мы моделируем запрос + POST.

Запросы + POST обычно используются для отправки данных на сервер. Это может быть использовано для оценки:

HTML-обработчики форм: используйте адрес, который находится в атрибуте + action + вашей HTML-формы:
```
<form action="/login.php">
...
</form>
```
+ POST + Конечные точки API: Если у вас есть API отдыха, используйте конечную точку, где вы создаете свою статью:
```
POST /articles
```

Начните с создания файла + scripts / post.lua + в * wrk1 * Droplet.

cd ~
mkdir scripts
nano scripts/post.lua

Добавьте к этому следующее содержание:

post.lua

wrk.method = "POST"
wrk.body   = "login=sammy&password=test"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"

Этот скрипт очень прост, и мы еще не использовали ни один из упомянутых методов. Мы только что изменили глобальные свойства объекта + wrk +.

Мы изменили метод запроса на + POST +, добавили некоторые параметры входа и указали заголовок + Content-Type + для использования HTML-форм MIME-типа.

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

изображение: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/container-overview.png [Визуализация контейнера Docker]

Теперь момент истины - сравните приложение с помощью этой команды (выполните для * wrk1 * Droplet):

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/post.lua http://$APP1_PRIVATE_IP:3000

Выход:

OutputRunning 5s test @ http://10.135.232.163:3000
 1 threads and 1 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     1.04ms  718.38us  12.28ms   90.99%
   Req/Sec     1.02k   271.31     1.52k    66.00%
 5058 requests in 5.00s, 0.97MB read
Requests/sec:   1011.50
Transfer/sec:    198.55KB

Вывод похож на тот, который мы видели ранее.

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

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

Пример: несколько путей URL

Другая распространенная потребность - это одновременное тестирование нескольких путей приложения.

Давайте создадим файл с именем + paths.txt + в каталоге + data + и добавим все пути, которые мы хотим использовать во время нашего теста.

cd ~
mkdir data
nano data/paths.txt

Найдите пример + data / paths.txt + ниже:

paths.txt

/feed.xml
/contact/
/about/
/blog/
/2015/04/21/nginx-maintenance-mode/
/2015/01/06/vagrant-workflows/
/2014/12/10/top-vagrant-plugins/

Затем захватите this простой скрипт и сохраните его как + scripts / множественный-url-paths.lua +:

множественная URL-paths.lua

-- Load URL paths from the file
function load_url_paths_from_file(file)
 lines = {}

 -- Check if the file exists
 -- Resource: http://stackoverflow.com/a/4991602/325852
 local f=io.open(file,"r")
 if f~=nil then
   io.close(f)
 else
   -- Return the empty array
   return lines
 end

 -- If the file exists loop through all its lines
 -- and add them into the lines array
 for line in io.lines(file) do
   if not (line == '') then
     lines[#lines + 1] = line
   end
 end

 return lines
end

-- Load URL paths from file
paths = load_url_paths_from_file("/data/paths.txt")

print("multiplepaths: Found " .. #paths .. " paths")

-- Initialize the paths array iterator
counter = 0

request = function()
 -- Get the next paths array element
 url_path = paths[counter]

 counter = counter + 1

 -- If the counter is longer than the paths array length then reset it
 if counter > #paths then
   counter = 0
 end

 -- Return the request object with the current URL path
 return wrk.format(nil, url_path)
end

Несмотря на то, что это руководство не пытается подробно учить скриптованию на Lua, если вы прочитаете комментарии в скрипте, вы можете получить хорошее представление о том, что он делает.

Сценарий + множественный url-paths.lua + открывает файл + / data / paths.txt +, и если этот файл содержит пути, они сохраняются во внутреннем массиве + paths +. Затем с каждым запросом берется следующий путь.

Чтобы запустить этот тест, используйте следующую команду (выполнить для * wrk1 * Droplet). Вы заметите, что мы добавили несколько разрывов строк, чтобы было проще копировать:

docker run --rm \
          -v `pwd`/scripts:/scripts \
          -v `pwd`/data:/data \
          williamyeh/wrk -c1 -t1 -d5s -s /scripts/multiple-url-paths.lua http://$APP1_PRIVATE_IP:3000

Выход:

Outputmultiplepaths: Found 7 paths
multiplepaths: Found 7 paths
Running 5s test @ http://10.135.232.163:3000
 1 threads and 1 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     0.92ms  466.59us   4.85ms   86.25%
   Req/Sec     1.10k   204.08     1.45k    62.00%
 5458 requests in 5.00s, 1.05MB read
Requests/sec:   1091.11
Transfer/sec:    214.17KB

Предварительные запросы с JSON и YAML

Теперь вы можете подумать, что другие инструменты бенчмаркинга также могут выполнять такие тесты. Однако wrk также может обрабатывать расширенные HTTP-запросы с использованием форматирования JSON или YAML

Например, вы можете загрузить файл JSON или YAML, который подробно описывает каждый запрос.

Автор опубликовал расширенный пример с запросом JSON на the технический блог автора.

С помощью wrk и Lua вы можете сравнивать любые типы HTTP-запросов.

Заключение

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

Наконец, вы можете пройти лишнюю милю с расширенными HTTP-запросами, используя сценарии Lua с wrk.

TOC

Как оценить латентность HTTP с помощью wrk в Ubuntu 14.04

Вступление

Предпосылки

Шаг 1 - Оба сервера: установите Docker

Шаг 2 - Подготовьте тестовое приложение

Шаг 3 - Установите wrk

Шаг 4 - Запустите WRK Benchmark Test

Шаг 5 - Оцените вывод

Шаг 6 - Примите меры для улучшения задержки

Имитация расширенных HTTP-запросов с помощью скриптов Lua

Части скрипта Lua для WRK

Пример: `+ POST +` запросы

Пример: несколько путей URL

Предварительные запросы с JSON и YAML

Заключение

Related

TOC

Как оценить латентность HTTP с помощью wrk в Ubuntu 14.04

Вступление

Предпосылки

Шаг 1 - Оба сервера: установите Docker

Шаг 2 - Подготовьте тестовое приложение

Шаг 3 - Установите wrk

Шаг 4 - Запустите WRK Benchmark Test

Шаг 5 - Оцените вывод

Шаг 6 - Примите меры для улучшения задержки

Имитация расширенных HTTP-запросов с помощью скриптов Lua

Части скрипта Lua для WRK

Пример: + POST + запросы

Пример: несколько путей URL

Предварительные запросы с JSON и YAML

Заключение

Related

Пример: `+ POST +` запросы