Очень интересные результаты обнаружились при тестировании nginx
При большом количестве параллельных запросов он как и положено
работает быстрее apache (интересует параметр fetches/sec):
:~>http_load -parallel 100 -seconds 10 nginx-empty
99305 fetches, 100 max parallel, 4.27012e+06 bytes, in 10.0001 seconds
43 mean bytes/connection
9930.39 fetches/sec, 427007 bytes/sec
msecs/connect: 0.548721 mean, 2.507 max, 0.175 min
msecs/first-response: 9.31641 mean, 38.666 max, 0.817 min
HTTP response codes:
code 200 -- 99305
:~>http_load -parallel 100 -seconds 10 apache-empty
36852 fetches, 100 max parallel, 1.58464e+06 bytes, in 10 seconds
43 mean bytes/connection
3685.19 fetches/sec, 158463 bytes/sec
msecs/connect: 0.282486 mean, 0.882 max, 0.177 min
msecs/first-response: 26.8112 mean, 32.541 max, 3.507 min
HTTP response codes:
code 200 -- 36852
nginx обслуживает в 3 раза больше запросов
Но если делать параллельно только один запрос, то nginx получается
значительно медленнее apache:
:~>http_load -parallel 1 -seconds 10 apache-empty
14081 fetches, 1 max parallel, 605483 bytes, in 10 seconds
43 mean bytes/connection
1408.1 fetches/sec, 60548.3 bytes/sec
msecs/connect: 0.312614 mean, 810.94 max, 0.17 min
msecs/first-response: 0.397542 mean, 26.348 max, 0.356 min
HTTP response codes:
code 200 -- 14081
:~>http_load -parallel 1 -seconds 10 nginx-empty
1382 fetches, 1 max parallel, 59426 bytes, in 10.0001 seconds
43 mean bytes/connection
138.198 fetches/sec, 5942.52 bytes/sec
msecs/connect: 0.173347 mean, 0.404 max, 0.168 min
msecs/first-response: 0.251083 mean, 0.553 max, 0.237 min
HTTP response codes:
code 200 -- 1382
nginx обслуживает в 10 раза меньше запросов
Понятно, что на практике такой случай не интересен, но тем не менее
есть теоретический интерес - а что же при этом происходит и где затык.
Конфиг апача
KeepAlive Off
MaxClients 10
больше вроде ничего хитрого нет.
В nginx
worker_processes 1;
tcp_nodelay on;
keepalive_timeout 0;
Остальное по умолчанию.
Когда на nginx один запрос в параллели
загрузка CPU - 99% idle
nginx всегда висит в состоянии kqread
И что подозрительно наблюдаются "зависшие" коннекты:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 85 0 81.19.67.55.8080 81.19.67.108.58002
ESTABLISHED
sleep 20
И видим то же самое соединение:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 85 0 81.19.67.55.8080 81.19.67.108.58002
ESTABLISHED
В stub_status при этом
Reading: 1 Writing: 1 Waiting: 0
Если ставить
worker_processes 3;
То производительность только падает.
Если смотреть tcpdump, то выглядит так:
Пролетает пачка примерно из N запросов (кол-во запросов в пачке
меняется от нескольких до нескольких тысяч), потом тишина (httpd_load
иногда даже по таймауту в такие моменты отваливается), потом снова
пачка из N запросов.
Насколько я понял отдельные запросы "подвисают" и при нескольких
параллельных запросах, но тогда это незаметно и на результат не
влияет.
nginx 0.3.33
OS на сервере FreeBSD 6.1-BETA2 и на клиенте 6.1-BETA4
Вот две соседние строчки из лога [$msec] $request_time "$request" $status
$bytes_sent
Это при запущенном http_load которые запросы шлет один за другим.
[1142972734.081] 0 "GET /empty.gif HTTP/1.0" 200 231
[1142972744.026] 0 "GET /empty.gif HTTP/1.0" 200 231
В error_log при этом пусто.
У меня похожие результаты на похожих же приборах (клиент 6.0-RELEASE, сервер
6.1-PRERELEASE). Забавность ситуации в том, что, если сказать nginx'у вести
отладочный лог, то его скорость резко возрастает и становиться близкой к
Апачу:
nginx: 9598 fetches, 1 max parallel, 412714 bytes, in 10 seconds
apache: 12087 fetches, 1 max parallel, 519741 bytes, in 10 seconds
А без лога nginx показывает иной раз такое:
77 fetches, 1 max parallel, 3311 bytes, in 10.0092 seconds
worker_priority не помогает.
Похоже, это проблема в kqueue в 6.1 (как минимум). При использовании
select nginx стабильно выдаёт
13427 fetches, 1 max parallel, 577361 bytes, in 10 seconds
Небольшое число (77) в предыдущих результатах - это число запросов,
успевших обработаться до таймаута.
Игорь Сысоев
