php e use o nginx para exibir arquivos estáticos Assim, o ponto chave é: qual deles é mais eficiente em atender a solicitações dinâmicas (não temos dúvidas de que o nginx é muito melhor que o apache para servir arquivos estáticos)?
O Nginx não oferece conteúdo dinâmico, ele só pode falar com algum tipo de back-end, que pode ser o processo Apache ou FastCGI (que pode ser executado em outro host). Se você comparar o Apache ao FastCGI, o último é mais fácil de configurar, mas o primeiro é, provavelmente, mais versátil. Tenho a impressão, no entanto, de que, para a maioria das ocasiões, o Nginx / FastCGI é bom o suficiente. YMMV.
Existe alguma configuração específica que você tenha em mente?
O PHP seria um conteúdo dinâmico, portanto, você não estaria usando a funcionalidade de cache de proxy reverso com o Nginx. Se você usou efetivamente o Nginx como um balanceador de carga para conteúdo dinâmico, certamente seria mais eficiente.
Se você está falando sobre um único servidor, colocar o Nginx na frente para o conteúdo dinâmico do proxy transparente vai adicionar uma camada adicional de processamento. Embora provavelmente minuto, tecnicamente introduziria sobrecarga adicional. No entanto, os ganhos de desempenho do cache provavelmente compensariam isso.
A única maneira de ter confiança em sua situação única é executar seus próprios benchmarks. Um utilitário como o Jmeter poderia ser usado para o teste de carga.
As pessoas geralmente usam 1 em sites maiores, mas 2 é deveria ser bom para. Existem pontos de referência , mas a maioria deles são sintético ou específico.
No geral, eles são bem próximos, mas eu diria que o nginx é mais fácil de configurar (ou melhor, mais difícil de configurar incorretamente) e é menos com fome de memória.
Por que não testar sua configuração específica com as duas opções em produção?
Eu não vejo o ponto de adicionar mais um ponto de falha introduzindo outro software, que essencialmente duplica a funcionalidade do outro. Se você está tendo problemas com o Apache servindo conteúdo estático, eu iria olhar para a configuração primeiro e não culpar o software real. O Apache é imensamente popular por um motivo.
Divida a estática e a dinâmica em dois hosts virtuais diferentes no apache (e, portanto, em diferentes nomes de host).
Aponte o nome do host dinâmico em seu servidor / loadbalancer ("origin").
CNAME o nome de host estático para quase qualquer CDN, dificilmente importa qual, e tem que CDN atuar como um proxy de cache de volta para sua origem.
Configure o apache corretamente, anotando a configuração do mod_expires (e as configurações do etag se estiver em cluster).
A quantidade resultante de solicitações que a sua origem realmente vê para conteúdo estático será tão trivialmente minúscula que será inútil complicar a configuração com um segundo servidor http.
Tecnicamente, se você é bom, e conhece bem as habilidades de manipulação do http do seu framework, você pode executar o material dinâmico através do CDN também (e deve), mas uma coisa de cada vez.Você verá que, quando atingir um determinado nível, migrará para o apache2-mpm-worker + fcgid para php. Nesse ponto, é melhor usar o Nginx como uma única solução.
Você poderia usar um CDN, no entanto, se decidir não usá-lo desde o início, considere facilitar a divisão de um nome de host ou facilitar a especificação de um domínio separado para conteúdo estático em seu sistema. Embora static.seudominio.com seja legal, qualquer cookie que você definir com .domain.com será transferido para static.seudominio.com, o que é um pequeno tráfego extra com cada solicitação de um recurso estático.
O Nginx / fastcgi será ligeiramente mais rápido que o apache2 / mod_php e aproximadamente equivalente ao apache2 / mpm-worker com fcgid. Simplifique sua pilha e use somente Nginx neste caso, considere usar o cache onde você puder. Lembre-se de que a velocidade é importante, atender volumes de tráfego alto às vezes é mais importante. Às vezes, servir 100 pessoas muito rapidamente não é tão bom quanto atender 10000 pessoas com bastante rapidez. O mod_php5 usa o prefork, que não controla muito bem o rebanho trovejante. Se o seu tráfego for rajada, você terá que implantar com o fcgid / fastcgi.
Existem alguns casos em que o Nginx / fastcgi introduz alguns bugs que você não vê com o apache2 / mod_php5, mas eles estão mais envolvidos nas variáveis de ambiente e na maneira como o php fala com o Nginx. Lembre-se que o proxy do Nginx é http / 1.0 - mesmo que o Nginx converse com o cliente com http / 1.1 - keepalives entre o Nginx e seu proxy não são suportados.
Dito isto, se você quisesse ficar com o Apache, o mpm-worker + fcgid / php5 ainda pode fazer muito bem e se você descarregar o conteúdo da sua imagem em um CDN, você tem uma situação que a maioria das pessoas pode facilmente diagnosticar . O Nginx não suporta o mod_rewrite da mesma maneira, existem módulos que você pode usar no apache que você não pode usar com o Nginx, diretivas do .htaccess não são suportadas (embora possam ser emuladas na configuração do Nginx).
Se você está acostumado a desenvolver em um ambiente apache, pode achar o Nginx confuso. Se você estiver desenvolvendo um projeto desde o início, talvez seja mais fácil implantá-lo hoje com o Nginx e, quando atingir esses problemas, você já os abordará. Se você implantar com o Apache hoje e depois tentar convertê-lo, poderá encontrar alguns problemas que não esperava.
Tags nginx apache-2.2