Estou executando um teste de estresse httperf simples em um servidor Nginx quad-core, apontado em um documento HTML / PHP. Grandes taxas de conexão começam rapidamente a experimentar altos tempos de conexão e resposta (veja o tempo mediano de conexão e o tempo de resposta nos resultados abaixo). O que torna este enigma é quando o teste é repetido em um servidor Apache que atende conteúdo idêntico.
O servidor Apache não se esforça relativamente. A única diferença que noto é nos valores "Net I / O", que são muito maiores ao testar o servidor Nginx (3315.6 KB / s vs 55.5 KB / s). O tempo de resposta também tem uma grande contribuição de "transfer" (849.6 ms) enquanto o servidor Apache tem "0.0" lá. Meu primeiro pensamento foi que o cache da web não estava funcionando no servidor Nginx, fazendo com que mais dados fossem transferidos, mas esse não era o caso, e o httperf não é um navegador de qualquer maneira.
Minha configuração do Nginx deveria, teoricamente, ser capaz de lidar com esse teste de estresse muito bem. Eu suspeito que os volumes de transferência de dados são a razão para o baixo desempenho.
Então, minha pergunta é: o que sobre uma configuração Nginx poderia explicar essa diferença na transferência de dados / tamanho do conteúdo em relação ao servidor Apache que hospeda conteúdo idêntico?
Aqui estão os resultados de httperf em ambos os servidores para um teste simples de 10 segundos com 1000 conexões:
httperf --hog --server xxx.xxx.xxx.xxx --uri /test.html --num-conns 1000 --rate 100
httperf --hog --client=0/1 --server=xxx.xxx.xxx.xxx --port=80 --uri=/test.html --rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 1000 requests 1000 replies 1000 test-duration 11.776 s
Connection rate: 84.9 conn/s (11.8 ms/conn, <=214 concurrent connections)
Connection time [ms]: min 158.2 avg 1608.1 max 2695.7 median 1729.5 stddev 532.2
Connection time [ms]: connect 373.9
Connection length [replies/conn]: 1.000
Request rate: 84.9 req/s (11.8 ms/req)
Request size [B]: 84.0
Reply rate [replies/s]: min 69.2 avg 79.0 max 88.8 stddev 13.9 (2 samples)
Reply time [ms]: response 384.6 transfer 849.6
Reply size [B]: header 194.0 content 39702.0 footer 2.0 (total 39898.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0
CPU time [s]: user 0.18 system 11.57 (user 1.5% system 98.3% total 99.8%)
Net I/O: 3315.6 KB/s (27.2*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
httperf --hog --server xxx.xxx.xxx.xxx --uri /test.html --num-conns 1000 --rate 100
httperf --hog --client=0/1 --server=xxx.xxx.xxx.xxx --port=80 --uri=test.html --rate=100 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 1000 requests 1000 replies 1000 test-duration 10.101 s
Connection rate: 99.0 conn/s (10.1 ms/conn, <=29 concurrent connections)
Connection time [ms]: min 53.0 avg 117.7 max 3074.8 median 72.5 stddev 264.3
Connection time [ms]: connect 79.7
Connection length [replies/conn]: 1.000
Request rate: 99.0 req/s (10.1 ms/req)
Request size [B]: 88.0
Reply rate [replies/s]: min 97.0 avg 99.2 max 101.4 stddev 3.1 (2 samples)
Reply time [ms]: response 38.1 transfer 0.0
Reply size [B]: header 231.0 content 255.0 footer 0.0 (total 486.0)
Reply status: 1xx=0 2xx=0 3xx=1000 4xx=0 5xx=0
CPU time [s]: user 1.23 system 8.86 (user 12.1% system 87.7% total 99.8%)
Net I/O: 55.5 KB/s (0.5*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
Acontece que a diferença na duração da resposta é metodológica. Não notei que o servidor Apache estava retornando todos os códigos 301 durante esse teste, porque os URLs estavam sendo reescritos. Tive que alterar o URL e o caminho do servidor para corresponder exatamente ao que as regras de reescrita aplicam. Depois disso, os comprimentos de conteúdo combinaram perfeitamente, e o servidor Apache na verdade lutou um pouco mais do que o Nginx neste teste.