Comparação de desempenho dos servidores Web RPi 3: Apache, Nginx e Lighttpd


11

Alguém já fez algum teste de comparação de desempenho real no RPi 3 em servidores Web populares:

  1. Apache2 - o servidor mais prevalente
  2. Nginx - o servidor que afirma ser o melhor desempenho
  3. Lighttpd - o servidor mais leve
  4. Ou um pacote que eu não ouvi falar

Algo parecido com este post de 4 anos para o RPi 2 . Seguindo os conselhos desse post, ampliei minha pesquisa de maneira mais geral e encontrei este artigo , mas considero-o levemente suspeito por ser uma empresa de hospedagem e preciso de uma resposta adaptada ao hardware do RPi 3.


4
Fora do tópico: Eu não entendo por que alguém vota uma pergunta sem dar uma dica do que há de errado com ela.
Joe Platano

2
Não sou agressivo nem passivo, nem procuro excluir sua pergunta. Eu estava muito ocupado no momento para postar um comentário explicando meu voto negativo. A primeira questão é que você está otimizando prematuramente. Você não definiu claramente o caso de uso (quais módulos / funcionalidades serão necessários etc.). Eu poderia continuar por mais alguns parágrafos, mas deixarei suas próprias palavras falarem por si mesmas: "Se o Nginx fará o que eu preciso, então isso parecerá um melhor pronto para uso (ou fora do apto) -get) solução a montar antes que os ajustes de desempenho comecem. "
22617 Steve Robillard

2
Se o Nginx fizer o que eu preciso (para que você possa descartar um ou mais servidores com base nos requisitos; portanto, sua pergunta é irrelevante. Você está colocando o carrinho à frente. Obtenha um sistema que funcione e se preocupe com Em segundo lugar, para responder sua pergunta depende da carga de trabalho específica, o uso do banco de dados será pesado ou gravado pesado? o sistema será vinculado ao banco de dados ou IO? Se o banco de dados não precisar ajustar o servidor da web a ajuda.
Steve Robillard

2
Mais uma vez citando que "ser capaz de servir a todos algo sem grande atraso é importante". Quanto é muito atraso? e, finalmente, "vi outras postagens sobre como ajustar o Apache e o Nginx para obter um melhor desempenho, mas isso parece muito trabalho apenas para criar uma configuração de teste para comparar as opções". Não é exatamente isso que você está pedindo que alguém faça por você nesta pergunta? Sem o benefício de dados reais de tráfego ou uma especificação completa do problema. Sem essas coisas, eles também podem consultar uma bola de cristal.
27617 Steve Jobs Robillard

Considerando a pegada de memória e as limitações do processador do PI, algo como uma configuração baseada em nó, juntamente com express em um servidor de E / S não bloqueado, seria mais útil? Novamente, depende do seu caso de uso. Você está servindo arquivos estáticos ou dinâmicos. É sua panela ter um aplicativo da web ou um site.
CoderX 28/05

Respostas:


5

Isso deve ser um comentário, mas é um pouco longo.

Embora eu ainda não tenha testado vários servidores da web no meu Pi, eu já executei muitos testes em servidores da Web executando no hardware do servidor x86. O que eu sei de lá é:

  1. a maioria das pessoas fica confusa com a diferença entre desempenho e capacidade - você verá muitas postagens alegando que o nginx é mais rápido que o apache (pré-fork), isso não é verdade , exceto sob carga pesada. Nginx (e poderoso) são ambos muito melhores em capacidade. E isso está no nível mais trivial de análise.

  2. Poucas pessoas veiculam conteúdo exclusivamente estático com seus servidores da Web (nesse cenário, o tux e o G-Wan deixam os servidores que você mencionou na poeira). O perfil de desempenho é altamente dependente da tecnologia da camada lógica e de sua integração com o servidor da web.

  3. O desempenho (e capacidade) depende de tudo o mais em execução no dispositivo.

Existem muitos recursos de um servidor de datacenter que são muito fáceis de viver sem se você tiver redundância adequada no nível de cluster (psu duplo, rede dupla, console remoto ...), no entanto, um PI de framboesa não faz o melhor sentido como web servindo a plataforma devido à E / S lenta do disco - você realmente precisa de algo com conectividade SATA, [i] SCSI, AOE ou infinita banda ao seu armazenamento. O Pi não possui uma interface SATA, possui apenas uma porta Ethernet e não conheço uma interface infinibanda ou SCSI.

(existem pequenos computadores de placa única que são uma escolha mais sensata para desenvolver a capacidade de serviço da Web - e um cluster deles pode fazer um bom sentido econômico, mas nesse cenário você está vendo vários nós com capacidade em camadas para terminação SSL, HTTP cache, servidor web, lógica de aplicativo e gerenciamento de dados).

A questão do mais rápido é difícil de definir, diferente para cada caso e impossível de responder.

No entanto, o maior erro que eu vejo repetidamente em TI é que as pessoas escolhem produtos com base em um único atributo, em vez de considerar o impacto mais amplo, tanto em termos de tecnologia quanto de pessoas envolvidas.


Bons pontos todos. Receio que este projeto tenha voltado a ser queimado.
Sandor Dosa

2

Temo que você precise descobrir por conta própria. Quando fiz essa pergunta para o meu RPi2, me deparei com o Siege e o initperf . Eu segui este exemplo para executar os benchmarks - apenas em vez de páginas html simples solicitei arquivos php. O desempenho do servidor da web também depende dos módulos cgi que você escolher. Um lighttpd simples de baunilha pode ser mais rápido que um Apache de baunilha. Se você estiver escolhendo / configurando o CGI inadequado, isso pode ser alterado e o Apache pode superar o Lighty.


Eu temo que você esteja certo. Vou começar a tentar resolver um método de teste e relatar de volta.
Sandor Dosa

@SandorDosa, manter-me atualizado, pls
Joe Platano

2

Eu escolhi a opção lighttpd pelos seguintes motivos:

  1. leve
  2. um dos mais fáceis de instalar
  3. roda no meu RPi2 nos últimos dois anos sem problemas (24x7)
  4. precisava de um bom e simples de usar como meu dispositivo de teste

Eu o uso como:

  1. monitorar a temperatura da CPU do meu sistema, a temperatura ambiente / ambiente e o gráfico de umidade
  2. Servidor FTP para trocar arquivos com meus parceiros de negócios e evitar o armazenamento de dados confidenciais em servidores de correio gratuitos de terceiros
  3. Muitos widgets da web para verificar o índice do mercado, como forex, títulos, ações, etc.
  4. código html de teste
  5. executar um script que fiz para verificar o correio, pois tenho muitas contas de correio, evitando bloqueios de marcação geográfica
  6. executar um blog simples (blog Nibble)
  7. trabalhar como honeypot para detectar (e bloquear) hackers no meu fio

apenas para citar alguns usos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.