Introdução
Há uma grande quantidade de servidores web. Cada um possui seus próprios benefícios, vantagens e propósitos…
O líder é o Apache, sem dúvidas. Mas há, pelo menos, dois outros servidores que são bons o bastante para serem mencionados: Nginx e Lighttpd.
Escopo
Hoje, uma das questões mais debatidas em discussões sobre servidores web é “Qual é o melhor: Lighttpd ou Nginx?”. Neste artigo, vamos tentar ajudar os administradores de rede decidir se devem usar Lighttpd ou Nginx.
Objetivo
Este artigo não é uma tentativa de provar a vantagem de algum servidor, mas apenas um exemplo de testes de comparação real. O objetivo é comparar dois servidores web, sem fazer qualquer ajuste de desempenho em configurações. Todos devem trabalhar com as configurações padrão. Para os testes, temos duas instâncias Amazonm1.medium com 64 bits, Ubuntu 12.04 com a instalação padrão apt-getednginx/lighttpd, php5-fpm com suporte para MySQL e uma instalação joomla padrão (2.5.6) padrão com dados de exemplos que vêm com o pacote de instalação.
Este artigo é sobre a comparação entre Nginx e Lighttpd: dois servidores web leves e versáteis, que são projetados para serem rápidos, leves e fáceis. Vamos deixar o Apache de lado neste artigo.
O Lighthttpd é pequeno e single threaded, assim a sua memória e seu consumo de cpu são menores. Ele é fácil de configurar e é rápido para páginas estáticas em HTML. Ele foi projetado para ser altamente escalável e resolver o problema C10K.
O Nginx é um servidor web baseado em eventos. Por ser um servidor assíncrono, ele oferece escalabilidade. Em um servidor baseado em processo, cada conexão simultânea requer uma thread que gera sobrecarga significativa. Um servidor assíncrono, como o Nginx, é baseado em eventos e processa pedidos em uma única (ou, pelo menos, em muito poucas) thread, o que permite que ele seja muito rápido.
Ferramentas
Para análise comparativa do servidor web, usaremos provavelmente a melhor ferramenta para esse propósito: Siege.
Para monitoramento da saúde Nginx e Lighttpd, vamos utilizar monitis-m3, outra ferramenta, que facilita a sua vida:
Monitoramento do tempo de carregamento: LoadTime.
Monitoramento do servidor web: Lighttpd-monitor e Nginx-monitor.
E monitor personalizado do bash para monitoramento do processo: Process-monitor.
Nós também usamos Dstat para reparo de memória, uso de CPU e Load Average.
Preparativos
Nada foi alterado para aumentar o desempenho nem nos servidores web nem na pilha do php + mysql.
A única modificação feita foi o aumento do ulimit para 10.000 em ambos os servidores.
Foram adicionados registros adequados para instâncias do Amazon em arquivos do host.
Foi suposto que AMI1 era uma instância com Nginx instalado e AMI2 com Lighttpd instalado apropriadamente.
Testes
Em primeiro lugar, é preciso esclarecer como nós fizemos nossos testes (servidor, ferramenta de benchmark, método, etc.). Então, os servidores são instâncias EC2 Medium.
Nós executamos as ferramenta de benchmarking do siege com a adição de sessões simultâneas a cada 2 minutos, começando com 5 e terminando com 60 conexões simultâneas. Como eu disse antes, temos um apt-get ed nginx e lighty com MySQL 5.1 e php-fpm padrão instalado. Abaixo estão os logs de execução e a saída dstat do siege durante o pico de load.
Logs do Siege:
NGINX:
Conn. |
Trans |
Elap Time |
Data Trans |
Resp Time |
Trans Rate |
Throughput |
Concurrent |
Failed |
5 |
503 |
119.90 |
6 |
1.19 |
4.20 |
0.05 |
4.99 |
0 |
10 |
482 |
119.98 |
6 |
2.46 |
4.02 |
0.05 |
9.88 |
0 |
20 |
484 |
119.99 |
6 |
4.86 |
4.03 |
0.05 |
19.59 |
0 |
30 |
467 |
119.99 |
6 |
7.32 |
3.89 |
0.05 |
28.49 |
8 |
35 |
390 |
119.99 |
5 |
8.58 |
3.25 |
0.04 |
27.87 |
71 |
40 |
50 |
119.99 |
0 |
9.54 |
0.42 |
0.00 |
3.98 |
401 |
45 |
2 |
120.00 |
0 |
9.61 |
0.02 |
0.00 |
0.16 |
495 |
50 |
0 |
119.99 |
0 |
inf |
0.00 |
0.00 |
0.00 |
550 |
55 |
0 |
119.99 |
0 |
inf |
0.00 |
0.00 |
0.00 |
605 |
60 |
0 |
119.99 |
0 |
inf |
0.00 |
0.00 |
0.38 |
660 |
Lighttpd:
Conn. |
Trans |
Elap Time |
Data Trans |
Resp Time |
Trans Rate |
Throughput |
Concurrent |
Failed |
5 |
454 |
119.11 |
5 |
1.30 |
3.81 |
0.04 |
4.96 |
0 |
10 |
432 |
119.99 |
5 |
2.74 |
3.60 |
0.04 |
9.87 |
0 |
20 |
440 |
119.99 |
5 |
5.32 |
3.67 |
0.04 |
19.52 |
0 |
30 |
419 |
119.99 |
5 |
7.93 |
3.49 |
0.04 |
27.70 |
16 |
35 |
115 |
119.99 |
1 |
9.50 |
0.96 |
0.01 |
9.10 |
287 |
40 |
2 |
119.97 |
0 |
10.07 |
0.02 |
0.00 |
0.17 |
438 |
45 |
0 |
119.99 |
0 |
inf |
0.00 |
0.00 |
0.00 |
495 |
50 |
0 |
119.99 |
0 |
inf |
0.00 |
0.00 |
0.00 |
550 |
55 |
0 |
60.17 |
0 |
inf |
0.00 |
0.00 |
0.88 |
1078 |
60 |
0 |
10.07 |
0 |
inf |
0.00 |
0.00 |
1.38 |
1083 |
Ok. Então, o que podemos ver aqui olhando nos logs? Pra mim, o Nginx é o vencedor definitivo! Após 45 conexões simultâneas, o Lighttpd estava totalmente morto, enquanto Nginx ainda estava, de alguma forma, aguentando. 50 para cima foram críticas para ambos, então nada a comentar aqui. Mas, mesmo antes disso, podemos ver que quase todos os loads do Nginx se comportam melhor do que Lighttpd. Você pode ver que todas as taxas de transferências são melhores em Nginx do que em Lighttpd.
Então, vou deixá-lo sozinho com esses números e colocarei abaixo mais gráficos que são muito mais agradáveis, os quais peguei a partir do Painel Monitis. O primeiro gráfico mostra tempo de carregamento http e o segundo, a quantidade de recursos utilizados, respectivamente, por Nginx e o Lighttpd.
Então, vamos ver o que temos aqui com Nginx:
Tempo de carregamento Http:
Até o tempo de transferência de 0,4 segundos, os resultados são bastante impressionantes, né?
Quantidade de recursos do sistema usados pelo Nginx (dstat output):
Legal, o Nginx usa a mesma quantidade de recursos, enquanto está carregado ou inativo.
Então, para mim, o gráfico e a saída do dtstat apresentam resultados bastante impressionantes. Eu estou feliz com o que eu vi do Nginx até agora. Vamos agora ver como gráfico Lighttpd e dstat output são.
Tempo de carregamento Http:
Muito semelhante ao Nginx, mas ainda mais rápido, com o de tempo de transferência mx de 0,3 segundos. Ótimo!
E o que acontece com os recursos?
Quantidade de recursos do sistema usados pelo Lighttpd (saída do dstat):
OK, o que posso dizer aqui: Lighttpd não parece tão leve em comparação com Nginx, especialmente quando ele é carregado!
Agora, vamos resumir o que conseguimos durante o teste e o que sabemos sobre esses dois servidores.
Na tabela abaixo, nós coletamos alguns dados sobre os servidores, o que nos dará uma imagem mais clara do que esses servidores são e qual é o mais preferível usar. Nós não vamos discutir casos especiais, quando o Lighttpd ou o Nginx têm algumas características específicas ou mesmo quando são extremamente importantes para o projeto especificado. Estes são apenas descritores gerais que são interessantes para a maioria dos usuários.
Desempenho de carregamento de dados
Load Testing Metrics |
Nginx |
Weight |
Lighttpd |
Weight |
Average response time | 6.22 | 9 | 6.14 | 10 |
Peak response time | 9.61 | 10 | 10.07 | 9 |
Error rates | 398 (math average) | 10 | 563 (math average) | 7 |
Throughput | 0.05 (max) | 10 | 0.04 (max) | 9 |
Concurrent Users | 45 (max) | 10 | 40 (max) | 8 |
Summary | 49 | 43 |
Criteria |
NGINX |
Weight(0-10) |
Architecture |
asynchronous server |
5 |
Programming language |
C |
5 |
Performance |
49 |
7 |
Load Balancer |
Yes |
10 |
Memcached |
direct support |
10 |
HTTP Health Check |
HTTP Healthcheck(3rd party Module) |
5 |
Protocols |
HTTP(S), IMAP(S), POP3(S), SMTP(S) |
10 |
Configuration |
Single ascii file |
5 |
Modules |
Modular architecture, has also 3rd party modules repository |
6 |
Proxy AJP |
non official https://github.com/yaoweibin/nginx_ajp_module |
3 |
Proxy WSGI |
native uWSGI 3rd party WSGI |
9 |
Resources usage at idle time |
Light |
10 |
Resources sage under load |
Light |
10 |
Security |
Bandwidth, connection and request policing Request filtering |
8 |
SSL support |
TLSv1.1/TLSv1.2/SSL/SNI |
9 |
Stability |
Stable |
10 |
License |
10 |
|
Community |
10 |
|
Popularity |
9.63% |
|
Commercial support |
5 |
|
Official repository |
Debian, Ubuntu, RedHat, CentOS,OpenSuse,AIX,FreeBSD |
10 |
History |
2004 – Current |
10 |
Development |
Extremely Active |
10 |
Production Ready |
YES |
10 |
Last Stable Release |
1.2.2 (July 3,2012) |
10 |
SUMMARY |
197 |
LightHTTPD
Lighttpd |
Weight(0-10) |
asynchronous server |
5 |
C |
5 |
43 |
7 |
yes |
10 |
via mod_cml |
5 |
no |
0 |
HTTP(S) |
3 |
Single ascii file |
5 |
Modular architecture http://redmine.lighttpd.net/projects/lighttpd/wiki/docs:configurationoptions |
5 |
Strange unknown |
0 |
as FastCGI |
3 |
Light |
10 |
Medium |
7 |
chroot, set UID, set GID protecting docroot strict HTTP-header parsing |
7 |
TLS/SSL/SNI |
7 |
Users report about memory leaks |
6 |
10 |
|
5 |
|
0.6% |
|
Not available |
0 |
Debian, Ubuntu, RedHat, CentOS,OpenSuse,Gentoo,FreeBSD |
9 |
2003 – Current |
10 |
Active |
8 |
YES |
10 |
1.4.31 (May 31,2012 ) |
9 |
141 |
Conclusão
Os dois servidores têm um comportamento bastante semelhante, mas parece que o Nginx se comporta melhor e tem um suporte melhor para a comunidade. Então, se alguém me perguntar qual deles escolher, eu vou dizer “Nginx”, já que é mais popular e você sempre terá mais informações sobre ele apenas pesquisando no Google o que precisar. Se você é um usuário corporativo e precisa de suporte comercial, o Nginx irá fornecê-lo em www.nginx.com. Já o Lighthttpd não vai (no entanto, não foi possível encontrar qualquer referência ao apoio comercial de Lighthttpd). E, de fato, notamos que o Nginx é mais ativamente desenvolvido e avança muito mais rápido que o Lighthttpd. No entanto, o fato de dois gigantes, a Wikipédia e o YouTube, usarem Lighthttpd nos faz acreditar que esse servidor é bom o suficiente para ser usado em grande escala pelos proprietários de sites.
No entanto, este e outros testes em vários recursos na web não são uma sentença. Você sempre pode fazer a sua própria escolha.
***
Texto original da equipe Monitis, liderada por Hovhannes Avoyan, disponível em http://blog.monitis.com/index.php/2012/08/22/nginx-vs-lighttpd/