Хорошо, я искал всюду, и я не могу найти подробный ресурс в Интернете для того, как интерпретировать результаты теста Apache ab server. Я провел несколько тестов с тем, что, как я думал, было совершенно разными параметрами, но видел очень похожие результаты (мне трудно думать, что это означает, что мой сайт отлично масштабируется!). Если есть подробный ресурс, на который кто-то может указать мне, как понять результаты этого теста, или если кто-то хочет создать его здесь, я думаю, что это было бы очень полезно для меня и других.
Как я должен интерпретировать результаты теста Apache ab?
Ответ 1
Разочарование, не так ли? Я пытаюсь сделать то же самое, посмотрю, как мой недавно выделенный и настроенный выделенный сервер сравнивается с другими.
То, что я заканчиваю, - это сравнение моего текущего производственного сервера (двухъядерного 4-гигабайтного ОЗУ) с новым сервером (четырехъядерный 8 ГБ оперативной памяти).
Мне нужно "хорошо играть" с моими бок о бок сравнениями, так как рабочий сервер работает, и я не хочу "ломать" сервер для своих пользователей.
Сравнение текущего vs new со следующей командой на php-странице, которая просто вызывает phpinfo(): ab -kc 20 -t 60
На моем текущем производственном сервере я вижу что-то вроде следующего, где он не мог выполнить задачу за заданный промежуток времени:
Time taken for tests: 60.1234 seconds
Complete requests: 24538
Failed requests: 58
(Connect: 0, Length: 58, Exceptions: 0)
Requests per second: 408.96 [#/sec] (mean)
Time per request: 48.905 [ms] (mean)
Time per request: 2.445 [ms] (mean, across all concurrent requests)
VS следующее на новом сервере, который завершил все тесты за половину времени:
Time taken for tests: 29.838791 seconds
Complete requests: 50000
Failed requests: 11
(Connect: 0, Length: 11, Exceptions: 0)
Requests per second: 1675.67 [#/sec] (mean)
Time per request: 11.936 [ms] (mean)
Time per request: 0.597 [ms] (mean, across all concurrent requests)
Теперь это не действительно "честный" тест, так как текущий сервер обрабатывает 20 веб-сайтов в дополнение к тестовому тесту. Кроме того, это действительно только тестирование apache и php.
Поставив этот же тест на один из моих более сложных домашних страниц, тот, который "чувствует" медленный на текущем сервере, вижу следующее: Текущий сервер:
Time taken for tests: 60.14170 seconds
Complete requests: 510
Requests per second: 8.50 [#/sec] (mean)
Time per request: 2353.497 [ms] (mean)
Time per request: 117.675 [ms] (mean, across all concurrent requests)
Новый сервер:
Time taken for tests: 60.18651 seconds
Complete requests: 1974
Requests per second: 32.89 [#/sec] (mean)
Time per request: 608.092 [ms] (mean)
Time per request: 30.405 [ms] (mean, across all concurrent requests)
Этот тест загружает динамически сгенерированную страницу Joomla CMS. Это немного больше, чем "реальный мир". Опять же, с новым сервером, не занимающимся текущим движением сайта, так что это не сравнение яблок с яблоками. Я не хочу тестировать намного сложнее или я рискую своим конечным пользователем на моих сайтах.
После переноса сайтов на новый сервер я планирую повторить вышеописанные тесты, чтобы я мог видеть, что влияет на мой обычный трафик сайта на бенчмаркинг. То же самое, что и для производства машин и холостых результатов.
Теперь я также смотрю на то, чтобы подчеркнуть новый сервер и убедиться, что он реагирует хорошо. Выполнение команды ab -n 50000 -c 200 Я наблюдаю за командой top и вижу, сколько CPU и памяти используется, а также * f5 * на странице в моем браузера, чтобы узнать, есть ли у меня какие-либо ошибки, а также узнать, сколько времени потребуется серверу для ответа.
Мой первый тест дал мне:
Concurrency Level: 200
Time taken for tests: 692.160011 seconds
Complete requests: 50000
Failed requests: 30102
(Connect: 0, Length: 30102, Exceptions: 0)
Write errors: 0
Non-2xx responses: 30102
Total transferred: 456568770 bytes
HTML transferred: 442928962 bytes
Requests per second: 72.24 [#/sec] (mean)
Time per request: 2768.640 [ms] (mean)
Time per request: 13.843 [ms] (mean, across all concurrent requests)
Transfer rate: 644.17 [Kbytes/sec] received
Обратите внимание на очень высокий уровень ошибок. Мой apache настроен на максимум 250 одновременных запросов, но у моего MySQL было всего 175. MySQL был здесь ошибкой. Он не смог обработать все запросы, исходящие от apache. Мои загружаемые страницы веб-браузера давали мне страницу ошибки подключения MySQL на многих обновлениях страницы.
Итак, я столкнулся с MySQL до 300 одновременных запросов (я уже делал это, но забыл перезапустить MySQL, так что это оказалось хорошим тестом - я определил необходимые изменения и случайно сделал эмпирический тест подтверждение необходимости изменения).
Следующий прогон дал мне следующие результаты:
Concurrency Level: 200
Time taken for tests: 1399.999463 seconds
Complete requests: 50000
Failed requests: 5054
(Connect: 0, Length: 5054, Exceptions: 0)
Write errors: 0
Non-2xx responses: 5054
Total transferred: 1016767290 bytes
HTML transferred: 995713274 bytes
Requests per second: 35.71 [#/sec] (mean)
Time per request: 5599.998 [ms] (mean)
Time per request: 28.000 [ms] (mean, across all concurrent requests)
Transfer rate: 709.24 [Kbytes/sec] received
Это заняло в два раза больше, но частота неудачных запросов была намного ниже. В принципе, сервер теперь настроен таким образом, чтобы иметь возможность обрабатывать не менее 200 одновременных просмотров страниц на одной из моих домашних страниц, но для их обслуживания потребуется 5 секунд. Не очень, но намного лучше, чем ошибки MySQL, которые я получал ранее.
Во время всего этого, использование центрального процессора сервера привязывается на 100% при "среднем загрузке", зависящем от 180. MySQL использует около 8-9% от ЦП и не использует большую часть ОЗУ, ve выделил его, поскольку я просто неоднократно забивал одну и ту же страницу, поэтому он касается только одной базы данных. 400 МБ 4 ГБ + он настроен на рост. Верх показывает использование буферов и кэширования памяти примерно на 50% от общей доступной ОЗУ. Поэтому, пока я загружаю машину с этим тестом, она не приближается к перегруженной точке. При использовании базы данных в реальном мире MySQL должен захватить большую часть памяти, которую я выделил, поэтому сервер должен быть почти близок к полной нагрузке в этот момент.
Следующим моим испытанием было тестирование apache при "полной загрузке" из 250 соединений ab -n 50000 -c 250
Concurrency Level: 250
Time taken for tests: 1442.515514 seconds
Complete requests: 50000
Failed requests: 3509
(Connect: 0, Length: 3509, Exceptions: 0)
Write errors: 0
Non-2xx responses: 3509
Total transferred: 1051321215 bytes
HTML transferred: 1029809879 bytes
Requests per second: 34.66 [#/sec] (mean)
Time per request: 7212.577 [ms] (mean)
Time per request: 28.850 [ms] (mean, across all concurrent requests)
Transfer rate: 711.73 [Kbytes/sec] received
Это показывает аналогичные результаты для теста соединения 200 с правильной крышкой подключения MySQL. Это хорошо для меня, я думаю. Мне не нравится 7 секунд, чтобы вернуть страницу, но я думаю, что могу улучшить это на уровне Joomla, включив кеширование в Joomla либо с APC, либо с Memcache, которые установлены, но еще не используются Joomla.
Пытаясь подтолкнуть мою удачу, я подумал, что попробую 300 одновременных подключений. ab -n 50000 -c 300Браузер показывает долгое ожидание быстрой загрузки страницы. В противном случае это не сильно изменит результаты.
Concurrency Level: 300
Time taken for tests: 1478.35890 seconds
Complete requests: 50000
Failed requests: 2266
(Connect: 0, Length: 2266, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2266
Total transferred: 1079120910 bytes
HTML transferred: 1057241646 bytes
Requests per second: 33.83 [#/sec] (mean)
Time per request: 8868.215 [ms] (mean)
Time per request: 29.561 [ms] (mean, across all concurrent requests)
Transfer rate: 712.99 [Kbytes/sec] received
Я не знаю, является ли моя интерпретация этих результатов "правильной", или если мне не хватает чего-то значащего, но с отсутствием инструкции, которую я мог бы найти, это то, что я придумал.
Я только что использовал результаты, чтобы убедиться, что у меня хороший коэффициент ответа - отсутствие идеальной реакции зависит от меня, но я не знаю, как видеть или воспроизводить ошибки таким образом, чтобы я мог их проверить.
Медленное время для запроса также касается меня, но я думаю, что я могу решить многие из них на уровне приложения.
Я уверен, что, хотя сервер будет медленно сканировать, он может справиться с ситуацией с большой нагрузкой.
Глядя на другие инструменты настройки производительности, такие как MonYog после этих тестов бенчмаркинга, также показал мне, что мои текущие конфигурации "достаточно хороши".
Мне хотелось бы, чтобы там было место, где люди опубликовали результаты тестов, которые я могу воспроизвести, с описанием аппаратного обеспечения и конфигурациями программного обеспечения, поэтому я знаю, насколько я "конкурентоспособен", или если у меня есть много работы, чтобы сделать все, чтобы наилучшим образом использовать мои оборудование. Таким образом, почему я публикую свои результаты.
Ответ 2
Обратите внимание, что для строки "неудачных запросов" неудавшийся запрос определяется путем сравнения длины подпоследовательных запросов друг к другу. Для динамического веб-сайта это не означает, что запрос вообще не удался! Поэтому не беспокойтесь о неудавшейся строке запроса.
Смотрите также: http://www.celebrazio.net/tech/unix/apache_bench.html
Ответ 3
В верхней части creuzerm ответить. Вот очень хорошая ссылка с дополнительной информацией
https://serverfault.com/questions/274252/apache-ab-please-explain-the-output
Относительно большей разницы между строками
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
Ответ 4
С одной стороны, AB является однопоточным (это нормально для старых одноядерных процессоров, таких как Pentium 4).
Для тестирования многоядерного процессора, на котором размещен веб-сервер (Nginx/Lighty с использованием нескольких процессов, Apache с использованием нескольких потоков), вы должны использовать Weighttp (который совместим с AB).
"Weighttp -t 6" будет запускать 6 клиентских потоков (напротив, "AB -t 6" выполнит 6-секундный тест).
Вы получите гораздо более релевантные результаты, используя несколько клиентских потоков (столько, сколько количество рабочих веб-серверов), которые должны соответствовать количеству ядер процессора ядра).
Ответ 5
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
первый из них связан со средним временем для запроса на одновременных пользователей, поэтому, если вы делаете тест для 1000 запросов и 200 одновременных пользователей, первым будет среднее время для каждого 200 запроса. вторая связана с общим временем запроса, которое является средним временем по всем 1000 запросам.