Почему при увеличении количества одновременных запросов увеличивается время ответа?

Question

[Виктор]

Тестировал кучей всевозможных способов, и наблюдаю одинаковую ситуацию
При увеличении количества одновременных запросов в 10 раз, соответственно увеличивается и время ответа
Среднее количество запросов в секунду при этом остается примерно одинаковым, и никакой процесс не упирается в CPU/Memory

Мне непонятно, в какое другое ограничение я уперся в таком тесте:
- в ограничение веб-сервера(для Ngnix это должны быть детские игры) ?
- в ограничение тестирующего кода(мне кажется ab также должен хорошо справлятся) ?
- в ограничение ОС (количество соединений, etc...) ?

Например тестировал не настроенный Nginx(под Windows 7) с помощью apache benchmark на 10/100/1000 одновременных запросов, на 10000 запросов в 1 КБ
Вот сводные данные
"Time per request" растет каждый раз на порядок
"Requests per second" первые два раза одинаков, на третий падает в два раза

Concurrency Level:    10      100      100
Requests per second:  885.61  878.22   390.39
Time per request:     11.292  113.867  2561.546

Такая же ситуация наблюдается, если:
- тестировать nginx, либо простейший Node.js сервер с cluster-ом
- тестировать с помощью ab, либо Node.js-скриптом(модуль http, либо request)
- тестировать на windows, либо на debian
- проделал это в куче разных вариаций(веб-сервер и тестирующая утилита на одном компьютере)
везде время запроса растет пропорционально количеству потоков

Вот более подробные логи ab:

Concurrency Level:      10
Time taken for tests:   11.292 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      12570000 bytes
HTML transferred:       10240000 bytes
Requests per second:    885.61 [#/sec] (mean)
Time per request:       11.292 [ms] (mean)
Time per request:       1.129 [ms] (mean, across all concurrent requests)
Transfer rate:          1087.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.6      1       4
Processing:     5   10   3.1     10     184
Waiting:        4    9   3.2      9     181
Total:          6   11   3.1     11     184

Concurrency Level:      100
Time taken for tests:   11.387 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      12570000 bytes
HTML transferred:       10240000 bytes
Requests per second:    878.22 [#/sec] (mean)
Time per request:       113.867 [ms] (mean)
Time per request:       1.139 [ms] (mean, across all concurrent requests)
Transfer rate:          1078.05 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      1      15
Processing:    14  112  15.2    111     363
Waiting:       12   94  25.4    100     363
Total:         14  113  15.2    112     364

Concurrency Level:      1000
Time taken for tests:   25.615 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      12570000 bytes
HTML transferred:       10240000 bytes
Requests per second:    390.39 [#/sec] (mean)
Time per request:       2561.546 [ms] (mean)
Time per request:       2.562 [ms] (mean, across all concurrent requests)
Transfer rate:          479.22 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  23.1      1     514
Processing:   520 2471 749.2   2747    3931
Waiting:      478 2408 735.6   2668    3659
Total:        521 2473 749.6   2748    3932

Answer 1

[Виталий Пухов]

Время на выполнение обязательно будет увеличиваться при увеличении числа одновременных запросов, это очевидно, по другому и быть не может. Другой вопрос почему так сильно увеличивается, 100 потоков это не так много, но время ответа слишком сильно выросло. Тут вопрос не столько в самом Ngnix, сколько в том что именно на нем крутится, какие запросы отправлялись и кто их отправлял. Криво построенный функционал может упираться например в дисковые операции или нерационально обращаться с БД или перегружать процессор (что маловероятно, ибо настолько кривой код все таки редкость). Можно проверить это предположение если повестить ramdisk на нее кинуть статическую html страничку и ее раздать в Ngnix, если по ней будут показатели на порядок лучше нужно проверять то, что на нем крутится. Если же нет, тогда можно проверять Ngnix.

Comments

[Виктор]

Эти цифры приведены для дефолтного(никак не настроенного) Nginx
Он отдает просто статическую страницу весом в 1 КБ с SSD-диска
Но на самом деле такая же ситуация с самым обычным NodeJS-сервером, который отдает страницу вообще из памяти

При этом так как и Nginx, и NodeJS оба используют асинхронную модель работы, и при этом даже близко не подбираются к полному использованию CPU/mem

В таких условиях мне не очевидно, почему должно увеличиваться время ответа

[Виктор]

И что еще более интересно, такая же ситуация наблюдается, если сравнивать 1/2/3 одновременных запроса

Time per request:       0.572 [ms] (mean)
Time per request:       0.912 [ms] (mean)
Time per request:       1.355 [ms] (mean)
<code>

[Виталий Пухов]

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

[Виктор]

Виталий Пухов: с помощью ApacheBench
также пробовал с помощью Node.js (модули http, request)
Если со своими скриптами я мог и ошибиться, то в ApacheBench должны быть правильные запросы

выполнял команду(от нее и результаты выше)
ab -n 10000 -c 10 http://127.0.0.1/