Может кто-нибудь объяснить, что означают эти результаты ApacheBench?

Я пытаюсь выяснить, как использовать ApacheBench и тестировать мой сайт. Я установил проект сайта по умолчанию (это ASP.NET MVC, но, пожалуйста, не ставьте стоп-чтение, если вы не являетесь человеком .NET).

Я ничего не менял. Добавить новый проект. Задайте настройку RELEASE. Выполнить без отладки. (поэтому в режиме LIVE). Да, это со встроенным веб-сервером, а не с производственным классом IIS или Apache или что-то еще.

Итак, вот результаты: -

C:\Temp>ab -n 1000 -c 1 http://localhost:50035/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        ASP.NET
Server Hostname:        localhost
Server Port:            50035

Document Path:          /
Document Length:        1204 bytes

Concurrency Level:      1
Time taken for tests:   2.371 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1504000 bytes
HTML transferred:       1204000 bytes
Requests per second:    421.73 [#/sec] (mean)
Time per request:       2.371 [ms] (mean)
Time per request:       2.371 [ms] (mean, across all concurrent requests)
Transfer rate:          619.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.1      0      16
Processing:     0    2   5.5      0      16
Waiting:        0    2   5.1      0      16
Total:          0    2   5.6      0      16

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

C:\Temp>

Теперь я точно не знаю, на что я должен смотреть.

Во-первых, я после количества запросов в секунду. Итак, если у нас есть требование обрабатывать 300 reqs/sec, то это говорит, что он обрабатывает и составляет в среднем 421 req в секунду?

Во-вторых, в чем причина добавления более параллельных? Как и в случае, если у меня 1000 ударов по 1 одновременно, как это отличается от 500 на 2 одновременных? Проверять, есть ли какой-либо код, который блокирует другие запросы?

Наконец, есть ли что-то важное, что я пропустил из результатов, которые я должен принять к сведению?

Спасибо:)

Ответ 1

в чем причина добавления дополнительных одновременно? Как и в случае, если у меня 1000 ударов на 1 одновременном, как это отличается до 500 на 2 одновременных? Тестировать если есть какой-либо код, который блокирует другие запросы?

Немного об этом, да: ваше приложение, вероятно, делает вещи, где concurrency может вызвать проблемы.

Несколько примеров:

страница пытается получить доступ к файлу - заблокировать его в процессе; это означает, что если другая страница должна получить доступ к одному и тому же файлу, ей придется подождать, пока первая страница не закончит работу с ней.
совершенно одинаково для доступа к базе данных: если одна страница записывает в базу данных, в зависимости от вашей СУБД есть какие-то блокирующие механизмы (будь то на основе таблиц или на основе строк или что-то еще)

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

Вы должны думать о том, сколько пользователей будет на месте одновременно, когда оно будет в производстве, и настройте concurrency; просто помните, что 5 пользователей одновременно на вашем сайте не означают, что вам нужно протестировать с помощью concurrency из 5 с ab:

реальные пользователи будут ждать пару секунд между каждым запросом (время, чтобы прочитать страницу, нажать ссылку,...)
ab не ждет совсем: каждый раз, когда страница загружается (т.е. запрос завершен), он запускает другой запрос!

Кроме того, две другие вещи:

ab только тесты для одной страницы - реальные пользователи будут перемещаться по всему веб-сайту, что может вызвать проблемы с concurrency, которые у вас не было бы при тестировании только одной страницы
ab загружает только одну страницу: он не запрашивает внешние ресурсы (думаю, CSS, изображения, JS,...); что означает, что у вас будет много других запросов, даже если они не будут дорогостоящими, когда ваш сайт будет в производстве.

Как побочный элемент: вы можете взглянуть на другие инструменты, которые могут выполнять гораздо более полные тесты, например siege, Jmeter, или OpenSTA: ab действительно приятно, когда вы хотите измерить, если что-то вы сделали, это оптимизировать вашу страницу или нет; но если вы хотите имитировать "реальное" использование вашего сайта, это гораздо более адаптировано.

Ответ 2

Да, если вы хотите узнать, сколько запросов в секунду ваш сайт может обслуживать, посмотрите строку "Запросы в секунду". В вашем случае это очень просто, так как вы выполнили ab с concurrency из 1. Каждый запрос в среднем составлял всего 2.371ms. 421 из них, один за другим, занимают 1 секунду.

Вам действительно нужно немного поиграть с concurrency, чтобы точно оценить емкость вашего сайта. До определенной степени concurrency вы ожидаете увеличения пропускной способности, так как несколько запросов обрабатываются параллельно IIS. Например. если ваш сервер имеет несколько процессоров/ядер. Также, если страница использует внешний IO (услуга среднего уровня или вызовы БД), процессор может работать по одному запросу, а другой ожидает завершения ввода-вывода. В определенный момент запросы/сек будут выравниваться, увеличиваясь concurrency, и вы увидите увеличение задержки. Увеличьте concurrency еще больше, и вы увидите, что ваша пропускная способность (req/sec) уменьшается, так как серверу приходится выделять больше ресурсов для жонглирования всех этих параллельных запросов.

Все, что сказано, большинство ваших запросов возвращаются примерно через 2 мс. Это довольно чертовски быстро, поэтому я предполагаю, что в терминах вызовов БД или среднего уровня мало что происходит, и ваша система, вероятно, максимизируется на процессоре при запуске теста (или что-то не так и происходит очень быстро. вы уверены, что ab получит страницу ответа, которую вы намереваетесь сделать? То есть вы думаете, что вы тестируете 1204 байта?). Что вызывает еще один момент: ab сам потребляет процессор тоже, особенно после того, как вы запустили concurrency. Таким образом, вы хотите запустить ab на другой машине.

Кроме того, если ваш сайт выполняет внешние вызовы для служб среднего уровня или БД, вы хотите настроить ваш machine.config для оптимизации количества потоков, распределенных IIS: http://support.microsoft.com/default.aspx?scid=kb;en-us;821268

И просто немного мелочей: время, затраченное на статистику, выполняется с шагом ~ 16 мс, поскольку это выглядит как гранулярность используемого таймера. То есть 80% ваших ответов не принимали 0 мс, они занимали некоторое время < 16ms.