нагрузочное тестирование

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

Сказав, что здесь наиболее распространенные и простейшие параметры:

-c: ( "Concurrency" ). Указывает, сколько клиентов (людей/пользователей) будут одновременно попадать на сайт. Пока ab запускается, клиенты будут -c попадать на сайт. Это то, что на самом деле решает количество стресса, которое ваш сайт пострадает во время теста.

-n: указывает, сколько запросов будет сделано. Это просто определяет длину эталона. Высокое значение -n со значением -c, которое может поддерживать ваш сервер, является хорошей идеей для обеспечения того, чтобы вещи не ломались под постоянным стрессом: это не то же самое, что поддерживать стресс в течение 5 секунд, чем в течение 5 часов.

-k: Это делает браузеры функциональности "KeepAlive" по своей природе. Вам не нужно передавать значение для -k, так как оно "boolean" (это означает, что вы хотите, чтобы ваш тест использовал заголовок Keep Alive из HTTP и поддерживал соединение). Поскольку браузеры делают это, и вы, вероятно, захотите моделировать стресс и поток, которые ваш сайт будет иметь в браузерах, рекомендуется выполнить этот тест.

Последний аргумент - это просто хост. По умолчанию он попадет в протокол http://, если вы его не укажете.

ab -k -c 350 -n 20000 example.com/

Выдав вышеприведенную команду, вы нажмете http://example.com/ с 350 одновременными соединениями до тех пор, пока не будет выполнено 20 тысяч запросов. Это будет сделано с помощью заголовка keep alive.

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

Чтобы узнать, сколько людей сайт может обрабатывать одновременно, просто посмотрите, не соответствуют ли время ответа (среднее время, минимальное время ответа и минимальное время ответа, неудачные запросы и т.д.) номера, которые ваш сайт может принять (разные сайты могут захотеть разных скорости). Вы можете запустить инструмент с разными значениями -c, пока не нажмете на место, где вы скажете: "Если я его увеличу, он начнет получать неудачные запросы и разрывается".

В зависимости от вашего сайта вы ожидаете среднего количества запросов в минуту. Это так сильно варьируется, вы не сможете имитировать это с помощью ab. Однако подумайте об этом так: если ваш средний пользователь будет бить 5 запросов в минуту, а среднее время отклика, которое вы считаете действительным, составляет 2 секунды, это означает, что 10 секунд из минуты 1 пользователь будет на запросы, что означает только 1/6 времени он будет ударять по сайту. Это также означает, что, если у вас есть 6 пользователей, которые нажимают на сайт одновременно с ab, у вас, вероятно, будет 36 пользователей в симуляции, хотя ваш уровень concurrency (-c) равен всего 6.

Это зависит от поведения, которое вы ожидаете от своих пользователей, используя сайт, но вы можете получить его из "Я ожидаю, что мой пользователь нажмет X-запросы в минуту, и я считаю, что среднее время ответа действительное, если оно равно 2 секундам". Затем просто измените свой уровень -c, пока не нажмете 2 секунды среднего времени отклика (но убедитесь, что максимальное время отклика и stddev все еще действительны) и посмотрите, насколько велики вы можете сделать -c.

Надеюсь, я объяснил это ясно:) Удачи.

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

Самый простой тест, который вы можете выполнить, - это выполнить 1000 запросов, по 10 за один раз (что приблизительно имитирует 10 одновременных пользователей, получающих по 100 страниц каждый) по длине теста.

ab -n 1000 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.example.com/

-n 1000 - количество запросов.

-c 10 сообщает AB, чтобы выполнить 10 запросов одновременно, вместо одного запроса за раз, чтобы лучше имитировать одновременных посетителей (по сравнению с последовательными посетителями).

-k отправляет заголовок KeepAlive, который просит веб-сервер не отключать соединение после выполнения каждого запроса, но вместо этого повторно использовать его.

Я также отправляю дополнительный заголовок Accept-Encoding: gzip, deflate, потому что mod_deflate почти всегда используется для сжатия вывода text/html 25% -75%, последствия которого не должны быть уволены из-за его влияния на общую производительность веб-сервер (т.е. может передавать 2x данных за один и тот же промежуток времени и т.д.).

Результаты:

Benchmarking www.example.com (be patient)
Completed 100 requests
...
Finished 1000 requests


Server Software:        Apache/2.4.10
Server Hostname:        www.example.com
Server Port:            80

Document Path:          /
Document Length:        428 bytes

Concurrency Level:      10
Time taken for tests:   1.420 seconds
Complete requests:      1000
Failed requests:        0
Keep-Alive requests:    995
Total transferred:      723778 bytes
HTML transferred:       428000 bytes
Requests per second:    704.23 [#/sec] (mean)
Time per request:       14.200 [ms] (mean)
Time per request:       1.420 [ms] (mean, across all concurrent requests)
Transfer rate:          497.76 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     5   14   7.5     12      77
Waiting:        5   14   7.5     12      77
Total:          5   14   7.5     12      77

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     14
  75%     15
  80%     16
  90%     24
  95%     29
  98%     36
  99%     41
 100%     77 (longest request)

Для простейшей интерпретации игнорируйте все, НО эта строка:

Requests per second:    704.23 [#/sec] (mean)

Умножьте это на 60, и у вас есть ваши запросы в минуту.

Чтобы получить результаты реального мира, вы захотите протестировать Wordpress вместо статического файла HTML или index.php, потому что вам нужно знать, как все работает вместе: включая сложный PHP-код и несколько запросов MySQL...

Например, результаты тестирования новой установки Wordpress в той же системе и WAMP-среде (я использую WampDeveloper, но есть также Xampp, WampServer и другие)...

Requests per second:    18.68 [#/sec] (mean)

Теперь 37x медленнее!

После теста нагрузки есть несколько вещей, которые вы можете сделать, чтобы улучшить общую производительность (запросы в секунду), а также сделать веб-сервер более стабильным при большей нагрузке (например, увеличение -n и -c имеет тенденцию разбивать Apache), о котором вы можете прочитать здесь:

Загрузка тестирования Apache с AB (сканирование Apache)

Шаги по настройке Apache Bench (AB) на окнах (IMO - рекомендуется).

Шаг 1 - Установите Xampp.
Шаг 2 - Открыть CMD.
Шаг 3 - Перейдите в пункт назначения apache (cd C:\xampp\apache\bin) из CMD
Шаг 4 - Вставьте команду (ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/)
Шаг 5 - Подождите. Ваш сделанный

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

Если вы хотите использовать команду ab для тестирования нескольких конечных точек API, с разными данными, все в то же время в фоновом режиме, вам нужно использовать команду nohup. Он запускает любую команду, даже когда вы закрываете терминал.

Я написал простой script, который автоматизирует весь процесс, не стесняйтесь его использовать: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-shell-script