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

Тестировал кучей всевозможных способов, и наблюдаю одинаковую ситуацию
При увеличении количества одновременных запросов в 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
  • Вопрос задан
  • 804 просмотра
Пригласить эксперта
Ответы на вопрос 1
Neuroware
@Neuroware
Программист в свободное от работы время
Время на выполнение обязательно будет увеличиваться при увеличении числа одновременных запросов, это очевидно, по другому и быть не может. Другой вопрос почему так сильно увеличивается, 100 потоков это не так много, но время ответа слишком сильно выросло. Тут вопрос не столько в самом Ngnix, сколько в том что именно на нем крутится, какие запросы отправлялись и кто их отправлял. Криво построенный функционал может упираться например в дисковые операции или нерационально обращаться с БД или перегружать процессор (что маловероятно, ибо настолько кривой код все таки редкость). Можно проверить это предположение если повестить ramdisk на нее кинуть статическую html страничку и ее раздать в Ngnix, если по ней будут показатели на порядок лучше нужно проверять то, что на нем крутится. Если же нет, тогда можно проверять Ngnix.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Искра Екатеринбург
от 80 000 до 100 000 ₽
Art gorka Санкт-Петербург
от 60 000 ₽