Учебники

Apache Bench — Краткое руководство

Октябрь 11, 2018

Apache Bench — Обзор

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

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

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

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

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

Что такое Apache Bench?

Apache Bench (ab) — это инструмент организации Apache для тестирования веб-сервера по протоколу гипертекстовой передачи (HTTP). Хотя он предназначен для измерения производительности веб-сервера Apache, он также может использоваться для тестирования любого другого веб-сервера, который одинаково хорош. С помощью этого инструмента вы можете быстро узнать, сколько запросов в секунду способен обслуживать ваш веб-сервер.

Особенности Apache Bench

Давайте посмотрим на важные функции и ограничения Apache Bench. Функции и ограничения перечислены ниже —

  • Будучи программным обеспечением с открытым исходным кодом, оно свободно доступно.

  • Это простая компьютерная программа командной строки.

  • Это независимый от платформы инструмент. Это означает, что он может быть вызван на Linux / Unix или на сервере Windows одинаково хорошо.

  • Он может проводить нагрузку и тестирование производительности только для веб-сервера — HTTP или HTTPS.

  • Это не растяжимо.

Будучи программным обеспечением с открытым исходным кодом, оно свободно доступно.

Это простая компьютерная программа командной строки.

Это независимый от платформы инструмент. Это означает, что он может быть вызван на Linux / Unix или на сервере Windows одинаково хорошо.

Он может проводить нагрузку и тестирование производительности только для веб-сервера — HTTP или HTTPS.

Это не растяжимо.

Apache Bench использует только один поток операционной системы независимо от уровня параллелизма (указанного в флаге -c). Следовательно, при тестировании серверов большой емкости отдельный экземпляр Apache Bench может сам по себе стать узким местом. Чтобы полностью насытить целевой URL, лучше использовать дополнительные экземпляры Apache Bench параллельно, если ваш сервер имеет несколько процессорных ядер.

предосторожность

Вы должны знать, что в Apache Bench нет директивы для увеличения параллелизма в определенных интервалах во время выполнения тестов. Поэтому выполнение нагрузочных тестов с использованием ab эквивалентно атаке типа «отказ в обслуживании» (DOS). Рекомендуется сообщить и получить предварительное разрешение от поставщика услуг VPS, если вы собираетесь проводить тестирование с высокой нагрузкой в ​​течение длительного периода времени. Они предоставят вам соответствующий интервал времени или сместят ваш узел для задачи нагрузочного тестирования.

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

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

Apache Bench — Настройка среды

В этой главе мы расскажем вам, как настроить вашу среду для Apache Bench на вашем VPS.

Системные требования

  • Память — 128 МБ

  • Дисковое пространство — нет минимальных требований

  • Операционная система — Нет минимальных требований

Память — 128 МБ

Дисковое пространство — нет минимальных требований

Операционная система — Нет минимальных требований

Установка Apache Bench

Apache Bench является автономным приложением и не зависит от установки веб-сервера Apache. Ниже приведен двухэтапный процесс установки Apache Bench.

Шаг 1 — Обновление базы данных пакетов. 

# apt-get update

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

Шаг 2 — Установите пакет утилит apache2, чтобы получить доступ к Apache Bench. 

# apt-get install apache2-utils

Apache Bench теперь установлен. Если вы хотите протестировать веб-приложение, размещенное на том же VPS, достаточно установить только веб-сервер Apache — 

# apt-get install apache2

Будучи утилитой Apache, Apache Bench автоматически устанавливается при установке веб-сервера Apache.

Проверка установки Apache Bench

Давайте теперь посмотрим, как проверить установку Apache Bench. Следующий код поможет проверить установку — 

# ab -V

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Когда вы видите вышеупомянутый вывод терминала, это означает, что вы успешно установили Apache Bench.

Создание привилегированного пользователя Sudo

С точки зрения безопасности, для системного администратора считается хорошей практикой создавать пользователя sudo вместо того, чтобы работать от имени пользователя root. Мы создадим тестового пользователя с именем test для этой цели — 

# useradd -m -d /home/test -g sudo test

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

# passwd test

Система запросит новый пароль для пользовательского теста. Вы можете ввести простой пароль, поскольку мы просто тестируем его, а не внедряем на рабочий сервер. Обычно команда sudo предлагает ввести пароль пользователя sudo; Рекомендуется не использовать сложный пароль, так как процесс становится громоздким.

Выход 

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

Тестирование сайта Apache.org

В этом разделе мы протестируем веб-сайт Apache.org. Давайте сначала переключимся на пользовательский тест sudo — 

# su test

Для начала мы проверим веб-сайт организации Apache, https://www.apache.org/ . Сначала мы запустим команду, а затем поймем вывод — 

$ ab -n 100 -c 10 https://www.apache.org/

Здесь -n — количество запросов, которые нужно выполнить для сеанса бенчмаркинга. По умолчанию выполняется только один запрос, который обычно приводит к непредставительным результатам сравнительного анализа.

И -c — это параллелизм, который обозначает количество одновременных запросов. По умолчанию один запрос за раз.

Таким образом, в этом тесте Apache Bench сделает 100 запросов с параллелизмом 10 на сервер организации Apache.

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

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

# ab [options .....]  URL

где,

  • ab — команда Apache Bench

  • параметры — флаги для конкретной задачи, которую мы хотим выполнить

  • URL — путь URL, который мы хотим проверить

ab — команда Apache Bench

параметры — флаги для конкретной задачи, которую мы хотим выполнить

URL — путь URL, который мы хотим проверить

Понимание выходных значений

Нам нужно понимать различные метрики, чтобы понимать различные выходные значения, возвращаемые ab. Здесь идет список —

  • Серверное программное обеспечение — это имя веб-сервера, возвращаемое в заголовке HTTP первого успешного возврата.

  • Имя хоста сервера — это DNS или IP-адрес, указанный в командной строке.

  • Порт сервера — это порт, к которому подключается ab. Если порт не указан в командной строке, по умолчанию будет установлено значение 80 для http и 443 для https.

  • Протокол SSL / TLS — это параметр протокола, согласованный между клиентом и сервером. Это будет напечатано, только если используется SSL.

  • Путь документа — это URI запроса, проанализированный из строки командной строки.

  • Длина документа — это размер в байтах первого успешно возвращенного документа. Если длина документа изменяется во время тестирования, ответ считается ошибкой.

  • Уровень параллелизма — это количество одновременных клиентов (эквивалентных веб-браузерам), использованных во время теста.

  • Время, затраченное на тесты — это время, затрачиваемое с момента создания первого сокетного соединения до момента получения последнего ответа.

  • Выполнено запросов — количество полученных успешных ответов.

  • Failed Requests — количество запросов, которые были признаны ошибочными. Если число больше нуля, будет напечатана другая строка, показывающая количество запросов, которые не были выполнены из-за подключения, чтения, неправильной длины содержимого или исключений.

  • Всего перенесено — общее количество байтов, полученных с сервера. Это число по сути количество байтов, отправленных по проводам.

  • Переданный HTML — общее количество байтов документа, полученных с сервера. Это число исключает байты, полученные в заголовках HTTP

  • Количество запросов в секунду — это количество запросов в секунду. Это значение является результатом деления количества запросов на общее время.

  • Время на запрос — среднее время, затраченное на запрос. Первое значение рассчитывается по формуле параллелизма * timetaken * 1000 / done, а второе значение рассчитывается по формуле timetaken * 1000 / done.

  • Скорость передачи — скорость передачи, рассчитанная по формуле totalread / 1024 / timetaken.

Серверное программное обеспечение — это имя веб-сервера, возвращаемое в заголовке HTTP первого успешного возврата.

Имя хоста сервера — это DNS или IP-адрес, указанный в командной строке.

Порт сервера — это порт, к которому подключается ab. Если порт не указан в командной строке, по умолчанию будет установлено значение 80 для http и 443 для https.

Протокол SSL / TLS — это параметр протокола, согласованный между клиентом и сервером. Это будет напечатано, только если используется SSL.

Путь документа — это URI запроса, проанализированный из строки командной строки.

Длина документа — это размер в байтах первого успешно возвращенного документа. Если длина документа изменяется во время тестирования, ответ считается ошибкой.

Уровень параллелизма — это количество одновременных клиентов (эквивалентных веб-браузерам), использованных во время теста.

Время, затраченное на тесты — это время, затрачиваемое с момента создания первого сокетного соединения до момента получения последнего ответа.

Выполнено запросов — количество полученных успешных ответов.

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

Всего перенесено — общее количество байтов, полученных с сервера. Это число по сути количество байтов, отправленных по проводам.

Переданный HTML — общее количество байтов документа, полученных с сервера. Это число исключает байты, полученные в заголовках HTTP

Количество запросов в секунду — это количество запросов в секунду. Это значение является результатом деления количества запросов на общее время.

Время на запрос — среднее время, затраченное на запрос. Первое значение рассчитывается по формуле параллелизма * timetaken * 1000 / done, а второе значение рассчитывается по формуле timetaken * 1000 / done.

Скорость передачи — скорость передачи, рассчитанная по формуле totalread / 1024 / timetaken.

Быстрый анализ результатов нагрузочного тестирования

Узнав о заголовках выходных значений из команды ab, давайте попробуем проанализировать и понять выходные значения для нашего начального теста —

  • Организация Apache использует свое собственное программное обеспечение веб-сервера — Apache (версия 2.4.7)

  • Сервер прослушивает порт 443 из-за https. Если бы это было http, это было бы 80 (по умолчанию).

  • Всего передано 58769 байт за 100 запросов.

  • Тест завершен за 1,004 секунды. Нет неудавшихся запросов.

  • Запросов в секунду — 99,56. Это считается довольно хорошим числом.

  • Время на запрос — 100,444 мс (для 10 одновременных запросов). Таким образом, для всех запросов это 100,444 мс / 10 = 10,044 мс.

  • Скорость передачи — 1338,39 [Кбайт / с] получено.

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

Организация Apache использует свое собственное программное обеспечение веб-сервера — Apache (версия 2.4.7)

Сервер прослушивает порт 443 из-за https. Если бы это было http, это было бы 80 (по умолчанию).

Всего передано 58769 байт за 100 запросов.

Тест завершен за 1,004 секунды. Нет неудавшихся запросов.

Запросов в секунду — 99,56. Это считается довольно хорошим числом.

Время на запрос — 100,444 мс (для 10 одновременных запросов). Таким образом, для всех запросов это 100,444 мс / 10 = 10,044 мс.

Скорость передачи — 1338,39 [Кбайт / с] получено.

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

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

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

Построение вывода Apache Bench

Здесь мы представим соответствующий результат, чтобы увидеть, сколько времени занимает сервер по мере увеличения количества запросов. Для этого мы добавим опцию -g в предыдущей команде, за которой следует имя файла (здесь out.data), в котором будут сохранены выходные данные ab — 

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

Давайте теперь посмотрим out.data, прежде чем мы создадим сюжет — 

$ less out.data

Выход 

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

Давайте теперь разберемся с заголовками столбцов в файле out.data —

  • время начала — это дата и время начала разговора.

  • секунд — то же самое, что и время начала, но в формате отметки времени Unix (date -d @ 1496160697 возвращает вывод времени начала).

  • ctime — это время соединения.

  • dtime — это время обработки.

  • ttime — это общее время (это сумма времени ctime и dtime, математически ttime = ctime + dtime).

  • wait — это время ожидания.

время начала — это дата и время начала разговора.

секунд — то же самое, что и время начала, но в формате отметки времени Unix (date -d @ 1496160697 возвращает вывод времени начала).

ctime — это время соединения.

dtime — это время обработки.

ttime — это общее время (это сумма времени ctime и dtime, математически ttime = ctime + dtime).

wait — это время ожидания.

Для наглядной визуализации того, как эти несколько элементов связаны друг с другом, взгляните на следующее изображение —

Несколько предметов

Если мы работаем над терминалом или где графика недоступна, gnuplot — отличный вариант. Мы быстро поймем это, пройдя следующие шаги.

Давайте установим и запустим gnuplot — 

$ sudo apt-get install gnuplot  
$ gnuplot

Выход 

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

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

gnuplot> set terminal dumb

Выход 

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

Так как наш терминал gnuplot теперь готов к графику ASCII, давайте построим данные из файла out.data — 

gnuplot> plot "out.data" using 9  w l

Выход 

  1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9 ****** +
       |                                                                   |
  1200 ++                       ********************************************
       |     *******************                                           |
  1000 ++    *                                                            ++
       |     *                                                             |
       |     *                                                             |
   800 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   600 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   400 ++   *                                                             ++
       |    *                                                              |
   200 ++   *                                                             ++
       |    *                                                              |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

Мы изобразили ttime, общее время (в мс) из столбца 9, относительно количества запросов. Мы можем заметить, что для первых десяти запросов общее время составляло почти 100 мс, для следующих 30 запросов (с 10- го по 40- е ) оно увеличивалось до 1100 мс и так далее. Ваш сюжет должен отличаться в зависимости от ваших out.data .

Тестирование нашего образца приложения

В предыдущей главе мы понимали, как использовать Apache Bench для тестирования стороннего веб-сайта. В этом разделе мы будем использовать этот инструмент для тестирования веб-приложения на нашем собственном сервере. Чтобы сохранить самоучитель в максимально возможной степени, мы решили установить приложение Python для демонстрационных целей; Вы можете выбрать любой другой язык, например PHP или Ruby, в зависимости от вашего уровня знаний.

Установка Python

Обычно Python установлен по умолчанию на серверах Linux.

Установка Bottle Framework и создание простого приложения

Bottle — это микро-фреймворк, написанный на python для создания веб-приложений, а pip — менеджер пакетов python. Введите следующую команду в терминале, чтобы установить Bottle — 

$ sudo apt-get install python-pip
$ sudo pip install bottle

Давайте теперь создадим маленькое приложение Бутылка. Для этого создайте каталог и переместитесь в него — 

$ mkdir webapp
$ cd webapp

Мы создадим новый скрипт python app.py внутри каталога webapp — 

$ vim app.py

Теперь напишите следующий код в файле app.py — 

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = 'localhost', port = 8080)

После добавления вышеуказанных строк сохраните и закройте файл. Сохранив файл, мы можем запустить скрипт python для запуска приложения — 

$ python app.py

Выход 

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.

Эти выходные данные показывают, что наше приложение работает на локальной машине на хосте http: // localhost и прослушивает порт 8080 .

Давайте проверим, правильно ли наше приложение отвечает на запросы HTTP. Поскольку этот терминал не может принимать какие-либо входные данные без выхода из приложения «Бутылка», нам необходимо войти в систему нашего VPS с помощью другого терминала. После входа в VPS с помощью другого терминала вы можете перейти к своему приложению, введя следующий код в новом терминале. 

$ lynx http://localhost:8080/

Lynx является браузером командной строки и обычно устанавливается по умолчанию в различных дистрибутивах Linux, таких как Debian и Ubuntu. Если вы видите следующий вывод, это означает, что ваше приложение работает нормально.

Выход

Рысь

Если вы видите вывод выше, это означает, что наше приложение работает и готово к тестированию.

Тестирование приложения с помощью разработанного веб-сервера

Обратите внимание, что в ab есть ошибка, и она не может протестировать приложение на локальном хосте. Поэтому мы изменим хост с localhost на 127.0.0.1 в файле app.py. Таким образом, файл изменится на следующее — 

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = '127.0.0.1', port = 8080)

Давайте теперь протестируем наше приложение, набрав следующую команду на том же терминале, на котором выполнялась команда lynx: 

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        WSGIServer/0.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.203 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      16500 bytes
HTML transferred:       1200 bytes
Requests per second:    493.78 [#/sec] (mean)
Time per request:       20.252 [ms] (mean)
Time per request:       2.025 [ms] (mean, across all concurrent requests)
Transfer rate:          79.56 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     1    6  28.2      2     202
Waiting:        1    6  28.2      2     202
Total:          1    6  28.2      2     202

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%    202
  99%    202
 100%    202 (longest request)

В то время как выход на первом терминале будет (100 раз) следующим образом — 

...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12   
...

Вы можете наблюдать, как различные значения исхода АБ изменились по сравнению с первоначальным тестом.

Тестирование приложения с многопоточным веб-сервером

В предыдущих тестах ab мы использовали веб-сервер по умолчанию, входящий в состав среды Bottle.

Теперь мы заменим однопоточный веб-сервер по умолчанию на многопоточный. Поэтому давайте установим многопоточную библиотеку веб-сервера, такую ​​как cherrypy или gunicorn, и попросим Bottle использовать ее. Мы выбрали огнестрельное оружие для демонстрационных целей (вы можете выбрать и другое) — 

$  sudo apt-get install gunicorn

И измените файл, то есть изменить с веб-сервера по умолчанию на gunicorn — 

...
run(server = 'gunicorn'...)
...

Давайте проверим приложение во втором терминале. 

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        gunicorn/19.0.0
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.031 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17200 bytes
HTML transferred:       1200 bytes
Requests per second:    3252.77 [#/sec] (mean)
Time per request:       3.074 [ms] (mean)
Time per request:       0.307 [ms] (mean, across all concurrent requests)
Transfer rate:          546.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      0       4
Processing:     1    2   0.7      3       4
Waiting:        0    2   0.8      2       3
Total:          2    3   0.6      3       5
WARNING: The median and mean for the initial connection time are not within a normal
        deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      4
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

Посмотрите, как количество запросов в секунду увеличилось с 493 до 3252. Это означает, что gunicorn подходит в качестве рабочего сервера для приложений на Python.

Тестирование нескольких URL одновременно

В этой главе мы узнаем, как тестировать несколько URL одновременно. Для этого нам нужно отредактировать файл приложения app.py, включив в него два URL-адреса: 

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello1')
def hello():
   return "Hello World! It is first URL."

@app.route('/hello2')
def hello():
   return "Hello World! It is second URL."

run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)

Создание простого сценария оболочки

Вы можете сделать это, создав сценарий оболочки с несколькими вызовами ab. Создайте файл test.sh и добавьте в него следующие строки: 

ab -n 100 -c 10 http://127.0.0.1:8080/hello1 
ab -n 100 -c 10 http://127.0.0.1:8080/hello2

Когда вы добавите вышеуказанные строки, сохраните и закройте файл. Сделайте файл исполняемым — 

chmod u+x test.sh

Давайте теперь запустим скрипт — 

./test.sh

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

Выход 

.
.
.
Document Path:          /hello1
Document Length:        732 bytes

Concurrency Level:      10
Time taken for tests:   0.040 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      90000 bytes
HTML transferred:       73200 bytes
Requests per second:    2496.13 [#/sec] (mean)
Time per request:       4.006 [ms] (mean)
Time per request:       0.401 [ms] (mean, across all concurrent requests)
Transfer rate:          2193.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       3
Processing:     1    3   1.0      4       5
Waiting:        0    3   1.2      4       4
Total:          1    4   0.6      4       5
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.
.
.
.

Сценарий оболочки для сохранения выходных данных Apache Bench в файл

Вы можете сохранить выходные данные Apache Bench в файл, создав сценарий оболочки с несколькими ab-вызовами. В конце каждой строки поместите &; это заставляет команду выполняться в фоновом режиме и позволяет следующей команде начать ее выполнение. Вы также захотите перенаправить вывод в файл для каждого URL, используя <имя файла>. Например, наш файл test.sh после модификации будет выглядеть следующим образом: 

$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &

Здесь test1.txt и test2.txt — это файлы для сохранения выходных данных.

Вы можете проверить, что вышеприведенный скрипт создал два файла, test1.txt и test2.txt, которые содержат выходные данные ab для соответствующих URL — 

$ ls -l

Выход 

...
-rw-r--r-- 1 root root  5225 May 30 12:11 out.data
-rwxr--r-- 1 root root   118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root    91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test2.txt
...

Бдительная ситуация

При использовании ab вы должны быть предупреждены о неудачном тесте без предупреждения. Например, если вы проверите неправильный URL, вы можете получить что-то похожее на следующее (мы намеренно изменили порт здесь). 

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:805/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:
Server Hostname:        127.0.0.1
Server Port:            805

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.002 seconds
Complete requests:      100
Failed requests:        150
   (Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests:    0
Total transferred:      0 bytes
HTML transferred:       0 bytes
Requests per second:    44984.26 [#/sec] (mean)
Time per request:       0.222 [ms] (mean)
Time per request:       0.022 [ms] (mean, across all concurrent requests)
Transfer rate:          0.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.2      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.2      0       0

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%      0 (longest request)

Подготовка к тестированию динамических страниц

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

Уровень параллелизма и общее количество запросов

Уровень параллелизма должен быть ниже общего количества запросов. 

$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Выход 

ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/path

Использование флагов

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

Verbose -v

Параметр verbose можно использовать для анализа и отладки, если существует несколько неудачных запросов. Распространенным признаком сбоя теста нагрузки является то, что тест завершается очень быстро и дает хорошее число для запроса в секунду. Но это будет неверный ориентир. Чтобы определить успех или неудачу, вы можете использовать опцию -v 2, которая будет выводить тело и заголовок каждого ответа на вывод терминала. Следующая команда описывает вариант использования — 

$ ab -n 1 -v 2 http://www.generic-example-URL.com/

Выход 

LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687

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

Keep-alive -k

Когда клиент отправляет HTTP-запрос, соединение устанавливается с сервером, сервер отправляет ответ, и соединение закрывается после того, как он отправил запрос. Этот цикл продолжается с каждым запросом. Однако с помощью параметра keep-alive (также известного как постоянные соединения) клиент поддерживает базовое TCP-соединение открытым, чтобы упростить множественные запросы и ответы; это устраняет медленное и дорогостоящее время инициализации соединения, которое в противном случае имело бы место.

Переменная длина документа -l

Если веб-страница имеет переменную длину, вам следует использовать опцию -l . Apache Bench не сообщает об ошибках, если длина ответов не постоянна. Это может быть полезно для динамических страниц.

Использование опции -r

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

Использование опции -H

Эта опция используется для добавления произвольной строки заголовка. Аргумент обычно имеет форму правильной строки заголовка, содержащей разделенную двоеточиями пару поле-значение (т. Е. «Accept-Encoding: zip / zop; 8bit»).

Использование опции -C

В следующем разделе мы подробно узнаем, как использовать вышеуказанные опции в сочетании с опцией использования значения cookie, то есть опцией -C . Опция -C обычно имеет форму пары имя = значение . Это поле может быть повторено.

Использование Session Cookie с Apache Bench

Чтобы понять, как использовать куки с Apache Bench, нам нужна веб-страница, которая пытается установить куки. Очень хорошим примером является приложение web2py, которое представляет собой веб-фреймворк Python.

Установка web2py

Мы собираемся быстро установить еще одно приложение python web2py. Вы можете прочитать больше о том, как его использовать, в Web2py Framework Overview .

Python обычно устанавливается по умолчанию на серверы Ubuntu и Debian. Таким образом, одно требование уже выполнено для успешного запуска web2py.

Однако нам нужно установить пакет unzip для извлечения исходных файлов web2py из zip-файла, который мы будем загружать — 

$ sudo apt-get update
$ sudo apt-get install unzip

Давайте получим фреймворк web2py с веб-сайта проекта. Мы загрузим это в нашу домашнюю папку — 

$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip

Теперь мы можем распаковать файл, который мы только что скачали, и переместить внутрь 

$ unzip web2py_src.zip
$ cd web2py

Чтобы запустить web2py, вам не нужно его устанавливать. Когда вы окажетесь в каталоге web2py, вы можете запустить его, введя следующую команду — 

$python web2py.py

Если все прошло успешно, вы увидите следующий вывод, где вас попросят выбрать пароль для административного интерфейса — 

web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:

please visit:
        http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server

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

Исходя из вывода, вы можете понять, что для остановки веб-сервера вам придется набрать «CTRL-C» в мгновенном терминале. С другой стороны, чтобы остановить сервер web2py на другом терминале, связанном с тем же VPS, вы можете вставить команду kill -SIGTERM <PID>, где <PID> — это идентификатор процесса для сервера web2py, который в данном случае 23904.

Сессионный Cookie от web2py

Если страница доступна только зарегистрированному пользователю, но не доступна напрямую со страницы входа, в этом случае вы можете использовать флаг -C . Этот флаг определяет cookie для команды ab. Но вы должны получить значение cookie идентификатора сеанса из действительного сеанса. Как это получить? Различные онлайн-учебники помогут вам освоить инструменты для разработчиков браузеров Chrome (или Mozilla). Но в нашем тестовом примере, поскольку приложение доступно только из командной строки, мы будем использовать браузер lynx для получения значения.

Давайте сначала получим значение cookie сеанса. Откройте другой терминал и введите следующую команду — 

$ lynx http://127.0.0.1:8000/

В ответ на приведенную выше команду lynx запросит у вас разрешение на прием файлов cookie с сервера web2py, как показано на рисунке ниже.

Сессионный Cookie от web2py

Запишите значение cookie, прежде чем вводить y, чтобы принять cookie. Теперь терминал будет выглядеть следующим образом — сайт на терминале!

Сайт в Терминале

Получив значение cookie, мы запустим тест ab. Для этого нам нужно будет открыть третий терминал (см. Изображение ниже) —

Значение Cookie

Теперь давайте используем флаг -C в третьем терминале — 

$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   0.051 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    1968.12 [#/sec] (mean)
Time per request:       5.081 [ms] (mean)
Time per request:       0.508 [ms] (mean, across all concurrent requests)
Transfer rate:          532.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.9      2       4
Processing:     0    3   0.9      3       5
Waiting:        0    2   1.1      2       4
Total:          4    5   0.7      5       7

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      6
  90%      6
  95%      6
  98%      7
  99%      7
 100%      7 (longest request)

Из приведенного выше вывода отметим несколько моментов. Во-первых, web2py использует веб-сервер Rocket . Мы также отмечаем, что мы получаем «Не-2xx ответы» в дополнение к ранее обсужденным заголовкам в выходных данных. В общем, протокол Http отвечает на запрос, используя код ответа, и все, что находится в диапазоне 200 с, означает «хорошо», а остальное соответствует некоторой проблеме. Например, 400 — это ошибки, связанные с ресурсами, например, 404 Файл не найден. 500 соответствуют ошибкам сервера. В нашем случае нет ошибок нигде, кроме случаев, когда мы используем опцию -C. Это может быть подавлено с помощью опции -l, как уже описано.

Проверка страницы администратора

В этом разделе мы поймем, как проверить страницу администратора. Для сравнения давайте проверим другой URL-адрес приложения web2py — 

$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/admin

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /admin
Document Length:        8840 bytes

Concurrency Level:      10
Time taken for tests:   2.077 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      926700 bytes
HTML transferred:       884000 bytes
Requests per second:    48.14 [#/sec] (mean)
Time per request:       207.749 [ms] (mean)
Time per request:       20.775 [ms] (mean, across all concurrent requests)
Transfer rate:          435.61 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    1   3.2      0      12
Processing:    62  204  52.2    199     400
Waiting:       61  203  52.0    199     400
Total:         62  205  54.3    199     411

Percentage of the requests served within a certain time (ms)
  50%    199
  66%    211
  75%    220
  80%    226
  90%    264
  95%    349
  98%    381
  99%    411
 100%    411 (longest request)

В частности, вам следует обратить внимание на соответствующие статистические данные в разделах «Время соединения» и «Процент обслуживаемых запросов» http://127.0.0.1:8000/ и http://127.0.0.1:8000/admin . Это огромная разница.

Использование опции Timelimit

Как правило, опция Timelimit довольно сложна. Давайте поймем это из руководства ab , которое довольно объяснительно — 

-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.

Давайте запустим тест с этой опцией. Мы отметим наши наблюдения после прохождения вывода — 

$ ab -n 100 -c 10 -t 60   http://127.0.0.1:8000/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   22.547 seconds
Complete requests:      50000
Failed requests:        0
Non-2xx responses:      50000
Total transferred:      13850000 bytes
HTML transferred:       3300000 bytes
Requests per second:    2217.61 [#/sec] (mean)
Time per request:       4.509 [ms] (mean)
Time per request:       0.451 [ms] (mean, across all concurrent requests)
Transfer rate:          599.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.8      2       8
Processing:     0    2   3.2      2     218
Waiting:        0    2   3.2      2     218
Total:          2    4   3.1      4     220

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      5
  90%      5
  95%      5
  98%      7
  99%      8
 100%    220 (longest request)

Обратите внимание, что выходные данные показывают, что эта опция переопределяет количество запросов, указанных параметром -n, и продолжается до 50 000 запросов. Однако, поскольку запросы обрабатывались очень быстро, ab прекращал работу, как только была достигнута отметка в 50 тыс. — в течение 22 секунд (см. Заголовок «Время, затраченное на испытания») в данном случае.

Вы можете протестировать ту же команду, заменив http://127.0.0.1:8000/ на http://127.0.0.1:8000/admin (при условии, что это наше приложение web2py) или сторонний веб-сайт, такой как https: //www.apache .org /, обратите внимание на разницу в статистике.

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

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

  • Убедитесь, что дополнительный модуль Python не загружен.

  • Чтобы избежать исчерпания порта TCP / IP, обычно следует подождать 2-3 минуты, прежде чем перейти к другому тесту ab.

  • Убедитесь, что число одновременных подключений меньше, чем у рабочих потоков Apache.

  • Вы должны перезагрузить сервер перед выполнением другого теста в случае сбоя Apache или python.

Убедитесь, что дополнительный модуль Python не загружен.

Чтобы избежать исчерпания порта TCP / IP, обычно следует подождать 2-3 минуты, прежде чем перейти к другому тесту ab.

Убедитесь, что число одновременных подключений меньше, чем у рабочих потоков Apache.

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

Последовательные тестовые случаи для динамических страниц

В этой главе мы опишем различные комбинации -n и -c с важными флагами, чтобы постепенно увеличить нагрузку на ваш веб-сервер.

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

  • Запросов в секунду
  • Время соединения (мс)
  • Процент запросов, обработанных в течение определенного времени (мс)

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

1 одновременный пользователь делает 100 страничных хитов

Давайте сделаем 100 последовательных загрузок страниц одним пользователем — 

$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      1
Time taken for tests:   0.045 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2206.24 [#/sec] (mean)
Time per request:       0.453 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          596.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.0      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.0      0       1

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      1
  95%      1
  98%      1
  99%      1
 100%      1 (longest request)

5 одновременных пользователей, каждый из которых делает 10 хитов

Этот случай соответствует пиковой нагрузке на сайт, которая получает около 50 000+ посещений в месяц. 

$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

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

Выход 

...
Requests per second:    2009.24 [#/sec] (mean)
Time per request:       2.488 [ms] (mean)
Time per request:       0.498 [ms] (mean, across all concurrent requests)
Transfer rate:          543.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      1       2
Processing:     0    1   0.5      1       2
Waiting:        0    1   0.5      1       1
Total:          2    2   0.4      3       3
ERROR: The median and mean for the total time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      3
  99%      3
 100%      3 (longest request)

10 одновременных пользователей, каждый из которых выполняет 10 страниц

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

$ ab  -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Выход 

...
Requests per second:    2225.68 [#/sec] (mean)
Time per request:       4.493 [ms] (mean)
Time per request:       0.449 [ms] (mean, across all concurrent requests)
Transfer rate:          602.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   1.0      2       3
Waiting:        0    1   1.0      2       3
Total:          4    4   0.3      4       4
WARNING: The median and mean for the waiting time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      4 (longest request)

20 одновременных пользователей, каждый из которых выполняет 20 просмотров страниц

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

$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/

Выход 

...
Requests per second:    1619.96 [#/sec] (mean)
Time per request:       12.346 [ms] (mean)
Time per request:       0.617 [ms] (mean, across all concurrent requests)
Transfer rate:          438.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.3      6      10
Processing:     1    5   2.9      5      10
Waiting:        0    5   2.9      5       9
Total:         10   11   0.6     11      12

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     11
  75%     12
  80%     12
  90%     12
  95%     12
  98%     12
  99%     12
 100%     12 (longest request)

30 одновременных пользователей, каждый из которых выполняет 30 просмотров страниц

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

$ ab  -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Выход 

...
Requests per second:    2283.45 [#/sec] (mean)
Time per request:       13.138 [ms] (mean)
Time per request:       0.438 [ms] (mean, across all concurrent requests)
Transfer rate:          617.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.7      6      11
Processing:     1    6   3.1      6      11
Waiting:        0    5   3.2      5      10
Total:         11   12   0.5     12      13

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     12
  80%     12
  90%     13
  95%     13
  98%     13
  99%     13
 100%     13 (longest request)

Теперь мы научились постепенно увеличивать нагрузку на сайт и тестировать его работоспособность.

Apache Bench — Сравнение выходов

В этой главе мы сравним результаты с флагами и без них. Давайте посмотрим, как использование соответствующих флагов может повысить производительность вашего веб-приложения. Перед этим нам нужно понять, как, если ваше приложение простое, вы можете не заметить разницу. Как и в случае с нашим простым приложением, с флагами и без флагов. Затем мы выполним тот же тест с https://www.apache.org/ URL и увидим разницу.

Тестирование нашего приложения без флагов

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

$ ab -n 100 -c 10 http://127.0.0.1:8000/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.244 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2208.77 [#/sec] (mean)
Time per request:       4.527 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          597.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.3      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      5
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

Тестирование нашего приложения с флагами

В этом разделе мы поймем, как протестировать наше приложение с флагами. 

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Выход 

...
Requests per second:    2277.07 [#/sec] (mean)
Time per request:       4.392 [ms] (mean)
Time per request:       0.439 [ms] (mean, across all concurrent requests)
Transfer rate:          615.97 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.2      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

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

Тестирование сайта организации Apache без флагов

Давайте теперь посмотрим, как протестировать веб-сайт Apache Organization без флагов. 

$ ab -n 100 -c 10 http://www.apache.org/

Выход 

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            80

Document Path:          /
Document Length:        58433 bytes

Concurrency Level:      10
Time taken for tests:   1.498 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5877500 bytes
HTML transferred:       5843300 bytes
Requests per second:    66.74 [#/sec] (mean)
Time per request:       149.840 [ms] (mean)
Time per request:       14.984 [ms] (mean, across all concurrent requests)
Transfer rate:          3830.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12  110 295.2     12    1012
Processing:    37   38   0.5     38      39
Waiting:       12   13   0.3     13      15
Total:         49  147 295.4     50    1051

Percentage of the requests served within a certain time (ms)
  50%     50
  66%     50
  75%     50
  80%     50
  90%    816
  95%   1050
  98%   1051
  99%   1051
 100%   1051 (longest request)

Тестирование сайта организации Apache с флагами

Теперь давайте проверим веб-сайт организации Apache с флагами. 

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://www.apache.org/

Выход 

...
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.357 seconds
Complete requests:      100
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      1358510 bytes
HTML transferred:       1317700 bytes
Requests per second:    280.28 [#/sec] (mean)
Time per request:       35.678 [ms] (mean)
Time per request:       3.568 [ms] (mean, across all concurrent requests)
Transfer rate:          3718.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.7      0      12
Processing:    14   17  21.3     15     227
Waiting:       14   17  21.3     14     227
Total:         14   18  21.5     15     227

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     15
  75%     15
  80%     15
  90%     27
  95%     28
  98%     29
  99%    227
 100%    227 (longest request)

Вы можете просто заметить, как увеличивается количество запросов в секунду с использованием флагов. В данном случае это, в частности, связано с использованием -H «Accept-Encoding: gzip , deflate, поскольку этот флаг указывает серверу Apache обслуживать запросы в формате gzipped .

Учитывая результаты Apache Bench

Несколько важных моментов необходимо учитывать, когда дело доходит до результатов Apache Bench. Это поможет нам разработать общую стратегию по устранению узких мест в нашем приложении и повышению его производительности.

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

Проверьте, есть ли ошибки в журналах ошибок Apache или используемого веб-сервера или (общих) журналах. Когда вы увеличите нагрузку, все начнет задыхаться: проблемы с памятью начнут возникать. Многие скрипты Python начнут падать, если они не написаны с учетом параллелизма.

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

Заключение

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

124
Share: