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

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

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

  • Memory - 128 МБ

  • Disk Space - Нет минимальных требований

  • Operating System - Нет минимальных требований

Установка Apache Bench

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

Step 1 - Обновить базу пакетов.

# apt-get update

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

Step 2 - Установите пакет apache2 utils, чтобы получить доступ к 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

Output

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; Рекомендуется не использовать сложный пароль, так как процесс становится громоздким.

Output

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.

Output

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

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

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

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

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

  • Server Software - Это имя веб-сервера, возвращенное в HTTP-заголовке первого успешного возврата.

  • Server Hostname - Это DNS или IP-адрес, указанный в командной строке.

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

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

  • Document Path - Это URI запроса, извлеченный из строки командной строки.

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

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

  • Time Taken for Tests - Это время, прошедшее с момента создания первого сокет-соединения до момента получения последнего ответа.

  • Complete Requests - Количество полученных успешных ответов.

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

  • Total Transferred- Общее количество байтов, полученных от сервера. Это число, по сути, количество байтов, отправленных по сети.

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

  • Requests per second- Это количество запросов в секунду. Это значение является результатом деления количества запросов на общее затраченное время.

  • Time per request- Среднее время, затраченное на запрос. Первое значение рассчитывается по формуле параллелизм * время * 1000 / сделано, а второе значение рассчитывается по формуле: время * 1000 / готово

  • Transfer rate - Скорость передачи, рассчитанная по формуле 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 помещает запросы в очередь ожидания.

В нашем первом тесте мы протестировали приложение (например, 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

Output

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 файл -

  • starttime - Это дата и время начала разговора.

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

  • ctime - Это время подключения.

  • dtime - Это время обработки.

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

  • wait - Это время ожидания.

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

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

Установим и запустим gnuplot -

$ sudo apt-get install gnuplot  
$ gnuplot

Output

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

Output

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

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

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

Output

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.