Apache vs Nginx


29

Eu tenho investigado as diferenças entre Apache e Nginx recentemente e estou confuso sobre qual devo escolher.

Eu fiz algumas pesquisas, mas não há comparação definitiva entre os dois e fiquei pensando se alguém aqui poderia dar suas opiniões sobre as diferenças entre os dois.

Meu conhecimento atual me permite entender que o mod_php é mais rápido e mais seguro que o fastcgi; no entanto, o Apache é muito pior quando se trata de conexões simultâneas e consumo de memória.

Meu site está usando muitas pesquisas longas, mas possui uma base da Web não AJAX (por exemplo, Apache com pesquisas longas por cima).

Minha solução original para problemas de memória do Apaches era enviar a pesquisa longa através do node.js e, em seguida, fazer com que o node.js acessasse o Apache a cada 2 segundos; nesse caso, o Apache não teria uma conexão aberta, mas sim o node.js. Cheguei à conclusão de que isso pode não ser bom o suficiente e estou procurando soluções diferentes. Ainda estou interessado em saber se minha ideia original teria funcionado.

Então, o que é melhor para a web moderna? Apache ou Nginx?

Atualização: Todas as sugestões dadas foram boas e válidas. Eu segui a segunda ideia original, que é usar um servidor Nginx completo. Estou satisfeito que, sendo um servidor dedicado, não sofri problemas de segurança com o fastcgi e, como meus longos scripts de pesquisa precisam ser escritos em PHP, preciso de um servidor que possa lidar com conexões simultâneas de alta carga e o Apache simplesmente não pode fazer isso, não importa quanto Eu mudo a estrutura que ainda estará com fome de memória.

Marquei a resposta de Martin F, já que ele deu uma resposta tão clara e completa às minhas perguntas, que sinto que ele merece a nota; no entanto, todas as três respostas foram boas e válidas e definirão definitivamente o uso de proxy reverso para outro site que possuo. desde que eu encontrei algo muito, muito, muito kool que o Nginx pode fazer em proxy.

Obrigado,

Respostas:


28

Você parece ter alguns conceitos errados que considero que precisam ser abordados.

Primeiro, o mod_php é apenas um pouco mais rápido, todos os meus testes mostraram que a diferença é tão minúscula que não vale a pena considerar. Também duvido que o aspecto de segurança seja relevante para você, pois você parece estar olhando para um servidor dedicado e O mod_php realmente tem apenas uma vantagem em um ambiente compartilhado - de fato, em um ambiente dedicado, o php-fpm terá a vantagem de que o PHP e seu servidor da Web agora executam processos diferentes, e isso nem sequer é considerado nas incríveis opções de log do php- fpm como log lento.

Se o mundo fosse preto e branco, eu diria que vá com uma configuração nginx pura e compile php com php-fpm. De forma mais realista, se você já possui o Apache funcionando, faça do nginx um proxy reverso para o apache, economizando algumas horas de tempo de configuração e a diferença de desempenho será pequena.

Mas vamos supor que o mundo seja preto e branco por um segundo, porque isso contribui para configurações muito mais impressionantes. Você faz nginx + php-fpm para o seu servidor web. Para resolver os uploads, use o módulo de upload e o módulo de progresso do upload para o nginx. Isso significa que seu servidor da Web aceita o upload e passa o caminho do arquivo para o PHP quando terminar, para que o arquivo não precise ser transmitido entre o nginx e o PHP via protocolo fastcgi, que bom. (Eu tenho isso em uma configuração ao vivo e está funcionando muito bem, btw!)

Para o download do usuário, você usa o recurso nginxs x-send-file-like chamado x-accel-redirect, essencialmente você faz sua autenticação no PHP e define um cabeçalho que o nginx pega e inicia a transferência desse arquivo. O PHP termina a execução e seu servidor da web está lidando com a transferência, querida! (Novamente, eu tenho isso em uma configuração ao vivo e está funcionando muito bem)

Para distribuir arquivos entre servidores ou outras operações de longa execução, percebemos que o PHP não é realmente o mais adequado para isso. Por isso, instalamos o gearman, que é um servidor de tarefas que pode distribuir tarefas entre trabalhadores em diferentes servidores; esses trabalhadores podem ser escritos em qualquer língua. Portanto, você pode criar um trabalhador de distribuição e gerar 5 deles usando um total de 200 KB de memória em vez dos 100 MB que o PHP usaria. Doce. (Eu também tenho essa execução ao vivo, então tudo é realmente possível)

Caso você ainda não tenha percebido, acho que muitos dos seus problemas não estão relacionados ao seu servidor da Web, você pensa assim porque o Apache o força a ser relacionado ao seu servidor da Web devido à sua estrutura, geralmente existem ferramentas muito melhores para o trabalho do que o PHP e o PHP é uma linguagem que sabe disso e oferece excelentes opções para descarregar o trabalho sem sair do PHP.

Eu recomendo o nginx, mas também acho que você deve procurar outras opções para seus outros problemas. Se você tiver um problema de dimensionamento ou desempenho, sinta-se à vontade para me escrever. Não sei se você pode enviar mensagens por aqui, mas escreva-me para martin@bbtn.us, pois não persigo a falha do servidor por algo que não esteja marcado com nginx. :)


1
Droga, isso realmente esclareceu as coisas :) Obrigado, essa foi a explicação que eu estava procurando. Eu acho que estou muito vendido aprendendo Nginx agora, já que o Apache sufocava e morria usando o meu site. Felizmente, parece realmente fácil movê-lo. Quero dizer que as pessoas no node.js disseram que escrevem a maioria das coisas e só pesquisam sua classe de sessão php se você realmente precisar (o que eu faço, a menos que haja uma maneira de detectar quando os usuários fecham suas janelas: P). Sim, eu estou correndo em um farm de servidores maciça lo sabendo que não há nenhuma ameaça de segurança ajuda toneladas, graças à grande explicação :)
Sammaye

Eu estive olhando isso: joeandmotorboat.com/2008/02/28/... e isso: blog.webfaction.com/a-little-holiday-present e tem realmente me kiddying com o pensamento de ser capaz de longo enquete para o meu coração conteúdo realmente. Nem um único problema de memória ao contrário Apache :)
Sammaye

Espere até que você esteja dizendo que eu poderia fazer um trabalhador multithread em java e o php possa solucionar isso perfeitamente? Quero dizer, o maior problema que vejo é o servidor, pois tenho enormes problemas de memória com o Apache usando pesquisas longas, o que é comum ... ofc corrigido pelo Nginx.
Sammaye 5/07

1
Essencialmente, sim, tenho trabalhadores de distribuição de arquivos escritos em C, usando a extensão gearman para PHP. Envio um trabalho de distribuição ao servidor de trabalhos gearman e o envia a um trabalhador, que pode ser escrito em qualquer idioma; PHP, Java, C, etc. Este trabalhador realiza seu trabalho e reporta o status ao gearman, que reporta ao PHP. (a menos que um trabalho de fundo foi escolhido, no caso extremidades PHP que sem esperar por ele)
Martin Fjordvald

2
Sei que essa é uma postagem antiga, mas devo dizer que essa é uma das postagens mais informativas que encontrei sobre o nginx vs apache. Thans Martin, +1.
Akoi Meexx

5

Eu sugeriria executar o nginx como um proxy reverso. Ele manipulará todos os seus arquivos estáticos e armazenados em cache (onde é consideravelmente mais rápido que o Apache / menos sobrecarga de memória) e encaminhará todas as solicitações de conteúdo dinâmico para o Apache.


Sim, este é o que a maioria das pessoas parecem estar fazendo atm eu vou definitivamente tem que olhar para isso :)
Sammaye

1
Lembre-se de instalar o mod_rpaf para Apache para que você possa passar pelos endereços IP do cliente para fins de registro (caso contrário, os logs do Apache mostrarão todas as solicitações como 127.0.0.1); adicione o seguinte ao nginx config: proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
Greg Annandale

Eu me pergunto uma coisa antes de tentar isso hoje à noite. Se eu estou roteando através do Nginx para o Apache, que serve o meu PHP, isso significa que pesquisas longas ainda terão os mesmos problemas que o Apache ou chamá-lo em proxy reverso fará com que o Apache aja de maneira diferente?
Sammaye 5/07

1

Não tenho tanta certeza de que o mod_php seja mais rápido que suas alternativas. Onde você leu isso? Fiz alguns testes de laboratório com nginx + php-fpm e, pelo que medi, supera todas as outras configurações.

Dê uma olhada nesta configuração: http://interfacelab.com/nginx-php-fpm-apc-awesome/

Configurei quase o mesmo, exceto pelo uso de pacotes PHP em http://www.dotdeb.org/ - que inclui um pacote php-fpm e um script init pronto para uso. Eu não uso memecache ou syck.


stackoverflow.com/questions/78108/… peguei a partir daqui e eu verifiquei o manual do php e diz que o php_mod oferece uma vantagem significativa sobre as versões do cgi. Sua configuração parece boa. Parece muito fácil também. Eu vou olhar para ele :)
Sammaye

2
Ele afirma que CGI é muito mais lento do que um módulo embutido - não FastCGI :)
pauska

1
Bem - se você está preocupado com a morte do processo PHP (ou o tempo limite), então o FastCGI (ou PHP-FPM) é o caminho a percorrer. Ele pode matar processos filhos mortos sem interromper outras atividades.
pauska 5/07

1
Sim. Ou, bem, isso depende. Quantos (máximo) número de solicitações lentas você processará ao mesmo tempo? Defina o máximo de threads do PHP FPM para isso, mais o número de cgi "rápidos" que você deseja disponíveis. Ouvi falar de pessoas executando 200 filhos de PHP-FPM em um servidor com 4 GB de RAM, por isso não me preocuparia muito se fosse você. A próxima versão do PHP (5.3.3) incluirá o PHP-FPM por padrão, onde também há um mecanismo adicional incluído - ele será escalado de acordo com o número de solicitações pendentes.
pauska

1
Eu rodaria facilmente em vários servidores (talvez até 10), mas se eu conseguir atender a 200 solicitações que podem ser pesquisadas em um servidor de 4 GB, isso deve ser quase metade dos 20 servidores necessários para executar o Apache. hmmmm ... vou precisar para testar isso esta noite
Sammaye
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.