Apache vs NGINX - Quem ganha em termos de desempenho?

Apache vs NGINX é um dos debates mais acalorados (desde o lançamento do NGINX) porque ambos são um dos servidores web mais comuns do mundo, seguidos por LiteSpeed ​​e OpenLiteSpeed.

Apache e NGINX alimentam quase 60% dos sites mundiais. Apache vs NGINX são semelhantes em termos de desempenho e recursos. Sua arquitetura, segurança e desempenho, por outro lado, são todos diferentes.

Pode ser difícil selecionar entre esses dois servidores porque ambos são excelentes. Como cada servidor web tem seu próprio conjunto de vantagens e desvantagens, é fundamental fazer a melhor opção possível.

Você também pode conferir o debate openlitespeed vs nginx aqui.

Comparação de velocidade Apache vs NGINX

Antes de aprofundar o debate Apache vs NGINX. Faremos primeiro um teste de velocidade simples, onde realizaremos o teste nos seguintes cenários.

• Vamos testar um pequeno arquivo estático de 5 KBytes
• Arquivo estático de tamanho 1 MB
• Testando um aplicativo PHP Hello World simples
• Benchmarking Apache vs NGINX para WordPress

Usamos o mesmo procedimento para testar openlitespeed vs nginx. O OpenLiteSpeed ​​é realmente uma ótima alternativa ao NGINX porque ele também suporta regras básicas de reescrita de .htaccess , assim você pode facilmente passar do Apache para o OpenLiteSpeed.

Vamos testar um pequeno arquivo estático de 5 KBytes

Veredicto Final : Ambos os servidores tiveram o mesmo desempenho com um pequeno arquivo estático.

Apache

NGINX

Arquivo estático de tamanho 1 MB

Veredicto Final : NGINX claramente ganhou com grande arquivo estático.

Apache

NGINX

Testando um aplicativo PHP Hello World simples

Veredicto Final : Ambos os servidores tiveram o mesmo desempenho com o aplicativo php hello world.

Apache

NGINX

Benchmarking Apache vs NGINX para WordPress

Veredicto Final : NGINX claramente ganhou com um site WordPress. Você pode usar este guia para acelerar sua loja WooCommerce

Apache

NGINX

Resultado do teste - Apache vs NGINX

Como podemos ver nos testes que o NGINX é relativamente melhor que o Apache em termos de velocidade. Os resultados são:

1. Teste um pequeno arquivo estático de 5 KBytes:

Neste teste, vemos que tanto o Apache como o NGINX estão dando os mesmos resultados relativos.

2. Teste um arquivo estático grande de 1 MB:

Neste teste, vemos que a velocidade do NGINX é muito melhor que a do Apache. O NGINX está dando um tempo médio de resposta muito menor.

3. Teste um aplicativo PHP Hello World simples

Neste teste, estamos vendo que tanto o Apache quanto o NGINX estão dando os mesmos resultados.

4. Teste para Apache vs NGINX para WordPress

Neste teste, vemos que o tempo médio de resposta do NGINX é muito menor que o do Apache, dando-lhe uma velocidade maior que a do NGINX.

Apache

Existe uma comunidade de desenvolvedores que mantém o Apache como um servidor web de código aberto. Ele usa arquitetura orientada a processos onde cria um novo thread para cada solicitação de conexão.
Além disso, o Apache oferece uma variedade de módulos que podem ser usados ​​para aumentar a funcionalidade do seu servidor web. O Apache é rápido, confiável, seguro e altamente personalizável para atender às necessidades de diferentes ambientes por meio do uso de extensões e módulos.

Arquitetura de manipulação de conexão

O Apache possui vários módulos de multiprocessamento (chamados MPMs pelo Apache) que controlam como as solicitações do cliente são tratadas. Essencialmente, isso permite que os administradores alternem rapidamente a arquitetura de manipulação de conexão.

• mpm-Prefor: Este Multi-Processing Module (MPM) implementa um servidor web de pré-bifurcação que não é encadeado. Cada processo do servidor pode responder a solicitações recebidas e o tamanho do pool de servidores é gerenciado por um processo pai. É adequado para sites que precisam evitar o encadeamento para trabalhar com bibliotecas que não são seguras para encadeamento. É também o melhor MPM para isolar cada solicitação, garantindo que um problema com uma não afete outras.
• mpm-worker: Um servidor multi-processo híbrido multi-thread é implementado por este Multi-Processing Module (MPM). Ele pode atender a um grande número de solicitações com menos recursos do sistema do que um servidor baseado em processo, pois usa threads para entregar solicitações. Ao manter vários processos disponíveis, cada um com muitos encadeamentos, ele mantém grande parte da estabilidade de um servidor baseado em processo.
• mpm-event: O evento Multi-Processing Module (MPM) destina-se a permitir que várias solicitações sejam atendidas ao mesmo tempo, delegando determinado processamento às threads do ouvinte, liberando as threads de trabalho para atender novas solicitações.
  O Apache tem um design flexível que permite escolher entre uma variedade de algoritmos de manipulação de conexão e solicitação. À medida que o cenário da Internet mudou, as escolhas apresentadas são principalmente um produto da evolução do servidor e do aumento da demanda por simultaneidade.

Conteúdo estático versus conteúdo dinâmico

O conteúdo estático pode ser tratado por servidores Apache usando seus mecanismos padrão baseados em arquivo. As abordagens MPM acima mencionadas são as principais responsáveis ​​pela execução desses procedimentos.

Além disso, o Apache pode processar conteúdo dinâmico incluindo um processador específico de linguagem em cada uma de suas instâncias de trabalho. Isso permite que ele execute conteúdo dinâmico sem o uso de componentes externos dentro do servidor web. Módulos carregáveis ​​dinamicamente podem ser usados ​​para habilitar esses processadores dinâmicos.

Como o Apache pode lidar com conteúdo dinâmico internamente, a configuração do processamento dinâmico geralmente é mais fácil. Os módulos podem ser trocados prontamente se os requisitos de conteúdo mudarem, e a comunicação não precisa ser coordenada com um software adicional.

Configuração distribuída vs. centralizada

Ao analisar e interpretar diretivas em arquivos ocultos dentro das próprias pastas de conteúdo, o Apache adiciona uma opção para permitir configurações adicionais por diretório. Os arquivos .htaccess são o nome desses arquivos.

Como esses arquivos estão localizados nas pastas de conteúdo, o Apache procura um arquivo .htaccess em cada componente do caminho para o arquivo solicitado e aplica as diretivas encontradas lá. Isso permite efetivamente a configuração descentralizada do servidor da Web, que é comumente usada para regravações de URL, limitações de acesso, autorização e autenticação e até políticas de cache.

Embora todos os exemplos anteriores possam ser configurados no arquivo de configuração principal do Apache, os arquivos .htaccess oferecem várias vantagens. Primeiro, porque eles são avaliados cada vez que são encontrados ao longo de um caminho de solicitação, eles são implementados sem exigir que o servidor seja recarregado. Em segundo lugar, ele permite que usuários não privilegiados controlem partes específicas de seu próprio conteúdo da Web sem dar a eles autoridade total sobre o arquivo de configuração.

Certos softwares da Web, como sistemas de gerenciamento de conteúdo, agora podem personalizar facilmente seu ambiente sem exigir acesso ao arquivo de configuração central. Os provedores de hospedagem compartilhada utilizam isso para manter o controle da configuração principal, oferecendo aos clientes acesso a seus diretórios específicos.

Interpretação baseada em arquivo vs. URI

O Apache pode interpretar uma solicitação como um recurso de sistema de arquivos físico ou um destino de URI que requer uma avaliação mais abstrata. Em geral, o Apache usa blocos <Directory> ou <File> para o primeiro, enquanto os blocos <Location> são usados ​​para recursos mais abstratos.

Como o Apache foi construído desde o início para ser um servidor web, ele interpreta as solicitações como recursos do sistema de arquivos por padrão. Para encontrar um arquivo real, ele começa com a raiz do documento e anexa a parte da solicitação seguindo o host e o número da porta. Na web, a hierarquia do sistema de arquivos é essencialmente representada pela árvore de documentos disponível.

Quando a solicitação não corresponde ao sistema de arquivos subjacente, o Apache oferece várias opções. Uma diretiva Alias, por exemplo, pode ser usada para mapear para um local diferente. O uso de blocos <Location> em vez do sistema de arquivos permite que você trabalhe diretamente com o URI. Variações de expressões regulares também estão disponíveis para aplicar a configuração de forma mais flexível em todo o sistema de arquivos.

Embora o Apache possa trabalhar tanto no sistema de arquivos subjacente quanto no espaço da web, ele prefere usar técnicas de sistema de arquivos. Algumas das decisões de design refletem isso, como o uso de arquivos .htaccess para configuração por diretório.

Módulo

O sistema de módulos no Apache permite carregar e descarregar módulos dinamicamente para atender às suas necessidades enquanto o servidor está em execução. O núcleo do Apache está sempre presente, mas os módulos podem ser habilitados ou desabilitados, adicionando ou excluindo funcionalidades e conectando-se ao servidor principal.

Esse recurso é usado pelo Apache para uma ampla variedade de tarefas. Devido à maturidade da plataforma, ela vem com uma grande biblioteca de módulos. Mod php, por exemplo, incorpora um interpretador PHP em cada trabalhador em execução e pode ser usado para alterar partes da funcionalidade essencial do servidor.

Por outro lado, os módulos não lidam apenas com conteúdo dinâmico. Eles podem reescrever URLs, autenticar clientes, proteger o servidor, registrar, armazenar em cache, compactar, fazer proxy, restringir taxa e criptografar dados, entre outras funções. Eles podem oferecer funcionalidade aprimorada sem adicionar muito trabalho.

Suporte, Compatibilidade, Ecossistema e documentação

Como o Apache existe há tanto tempo, há muito suporte para ele. Para o servidor núcleo e situações baseadas em tarefas que envolvem conectar o Apache a outro software, há uma biblioteca substancial de documentação própria e de terceiros acessível.

Muitas ferramentas e projetos da Web contêm ferramentas para auto-inicialização em um ambiente Apache, além da documentação. Isso pode ser fornecido nos próprios projetos ou nos pacotes que a equipe de empacotamento da sua distribuição mantém.

Devido à sua participação de mercado e ao tempo em que está disponível; O Apache receberá mais suporte de projetos de terceiros em geral. Os administradores também são mais propensos a ter trabalhado com o Apache, não apenas por causa de seu uso generalizado, mas também porque muitas pessoas começam suas carreiras em ambientes de hospedagem compartilhada, onde o Apache é usado virtualmente apenas devido aos recursos de gerenciamento distribuído .htaccess .

Vantagens do Apache vs NGINX

Muitos webmasters e desenvolvedores preferem o Apache ao NGINX, pois é muito mais antigo. É compatível com os sistemas operacionais Windows, Unix e Linux.

• Para servir material dinâmico, este é um excelente desempenho.
• Carregar e descarregar módulos dinamicamente.
• Fornece um arquivo .htaccess por diretório que pode ser usado para anular as configurações de todo o sistema.
• O suporte e a documentação são excelentes.
• O modelo usa uma abordagem de uma conexão por processo.
• Inclui os módulos mod_evasive e mod_security, que adicionam uma camada extra de segurança.

Desvantagens do Apache vs NGINX

• Incapaz de lidar com um grande número de solicitações ao mesmo tempo.
• Quando comparado ao NGINX, leva mais tempo para exibir conteúdo estático.
• Ele oferece amplos recursos de configuração e gerenciamento. Como resultado, não é apropriado para iniciantes.
• Os sites com muito tráfego têm problemas de desempenho.

NGINX

Na tentativa de superar o problema “C10k”, o codificador russo Igor Sysoev inventou o NGINX. Igor cumpriu seu objetivo: o NGINX pode gerenciar facilmente mais de 10.000 conexões simultâneas. Para lidar melhor com novas conexões, o NGINX possui um design assíncrono e orientado a eventos. NGINX é um servidor web que oferece muitos recursos. Abaixo estão listados alguns deles:

• Um cache HTTP e um balanceador de carga
• Proxy front-end do Apache e de outros servidores web.
• Os protocolos HTTP, HTTPS, SMTP, POP3 e IMAP são todos servidos por este servidor proxy reverso.

Desde seu lançamento, o NGINX aumentou em popularidade devido ao baixo uso de recursos e capacidade de dimensionar efetivamente em hardware de baixo custo. O NGINX é um servidor web especializado em servir material estático rapidamente e foi projetado para encaminhar solicitações dinâmicas para softwares mais adequados para essas tarefas.

Arquitetura de manipulação de conexão

O NGINX entrou em cena depois do Apache, com uma melhor compreensão dos problemas de simultaneidade que os sites em escala enfrentariam. O NGINX foi construído desde o início usando um algoritmo de manipulação de conexão assíncrona, não bloqueante e orientada a eventos para aproveitar essas informações.

O NGINX gera processos de trabalho, cada um dos quais é capaz de lidar com dezenas de milhares de conexões. Os processos de trabalho conseguem isso desenvolvendo um mecanismo de loop rápido que verifica e processa eventos regularmente. Ao desacoplar o trabalho real das conexões, cada trabalhador pode se concentrar em uma conexão somente quando um novo evento ocorrer.

Cada uma das conexões do trabalhador é colocada no loop de eventos, onde coexistem com outras conexões. Os eventos são processados ​​de forma assíncrona dentro do loop, permitindo que o trabalho seja feito de maneira não bloqueante. O link é excluído do loop após o fechamento.

O NGINX pode escalar excepcionalmente com recursos mínimos, graças ao seu método de processamento de conexão. Como o servidor é de thread único e nenhum processo adicional é gerado para lidar com cada nova conexão, o uso da memória e da CPU permanece relativamente constante, mesmo quando o servidor está sob intensa pressão.

Conteúdo estático versus conteúdo dinâmico

O NGINX não tem suporte nativo para processamento de conteúdo dinâmico. O NGINX deve passar PHP e outras solicitações de conteúdo dinâmico para um processador externo para processamento e, em seguida, aguardar o retorno do conteúdo renderizado. O cliente pode então ser informado das descobertas.

Para administradores, isso implica que a comunicação entre o NGINX e o processador deve ser configurada usando um dos protocolos que o NGINX entende (http, FastCGI, SCGI, uWSGI, memcache). Isso pode tornar as coisas um pouco mais complicadas, especialmente ao estimar o número de conexões a serem permitidas, porque cada chamada para o processador exigirá uma nova conexão.

Essa estratégia, por outro lado, oferece alguns benefícios. A sobrecarga do interpretador dinâmico estará presente apenas para material dinâmico porque não está incluído no processo de trabalho. O conteúdo estático pode ser enviado de forma simples, sendo o intérprete consultado apenas quando necessário. Isso também é possível com o Apache, mas elimina os benefícios mencionados na seção anterior.

Configuração distribuída vs. centralizada

O NGINX não entende arquivos .htaccess e não tem como avaliar a configuração por diretório fora do arquivo de configuração principal. Embora menos versátil que a abordagem Apache, ela tem seu próprio conjunto de benefícios.

O aumento de desempenho é o ganho mais notável sobre a abordagem .htaccess de configuração em nível de diretório. Para cada solicitação, o servidor verificará esses arquivos em cada um dos diretórios pai que levam ao arquivo solicitado em uma configuração padrão do Apache que permite .htaccess em qualquer diretório. Se esta busca encontrar um ou mais arquivos .htaccess , eles devem ser lidos e processados. O NGINX pode atender solicitações mais rapidamente executando uma única consulta de diretório e um arquivo lido para cada solicitação, não permitindo substituições de diretório (supondo que o arquivo seja encontrado na estrutura de diretório convencional).

Outra vantagem é que é seguro. A distribuição de acesso à configuração em nível de diretório também distribui as responsabilidades de segurança para usuários individuais, que podem ou não ser confiáveis ​​para fazê-lo corretamente. Ao garantir que o administrador tenha controle total sobre o servidor da Web, você pode evitar vários erros de segurança que podem surgir quando o acesso é concedido a outras pessoas.

Se você estiver preocupado com esses problemas, lembre-se de que você pode desabilitar a interpretação de .htaccess no Apache.

Interpretação baseada em URI de arquivo VS

O NGINX foi projetado para operar como servidor web e também como servidor proxy. Funciona amplamente com URIs, traduzindo para o sistema de arquivos quando necessário, devido à arquitetura necessária para esses dois trabalhos.

Isso pode ser visto na forma como os arquivos de configuração do NGINX são criados e processados ​​em alguns casos.
O NGINX não tem uma maneira de especificar a configuração de um diretório do sistema de arquivos, portanto, ele analisa o URI.

Os blocos de servidor e local, por exemplo, são os blocos de configuração mais importantes para o NGINX. O bloco de servidor é responsável por interpretar o host solicitado, enquanto os blocos de localização são responsáveis ​​por combinar partes do URI após o host e a porta. A solicitação agora está sendo processada como um URI em vez de um local do sistema de arquivos.

Todas as solicitações de arquivos estáticos devem eventualmente ser mapeadas para um local no disco. O NGINX seleciona os blocos de servidor e local que processarão a solicitação primeiro e, em seguida, combina a raiz do documento com o URI, modificando conforme necessário com base nas configurações.

Isso pode parecer semelhante, mas interpretar solicitações em grande parte como URIs em vez de localizações do sistema de arquivos torna mais fácil para o NGINX servir como servidor web, de correio e proxy. O NGINX é configurado definindo como ele deve responder a determinados padrões de solicitação. O NGINX não inspeciona o sistema de arquivos até que esteja pronto para entregar a solicitação, razão pela qual os arquivos .htaccess não são suportados.

Módulos

O NGINX também possui um sistema de módulos, porém é consideravelmente diferente do Apache. Os módulos no NGINX não podem ser carregados dinamicamente, portanto, eles precisam ser escolhidos e compilados no software principal.
O NGINX se tornará muito menos adaptável para muitos usuários como resultado disso. Isso é particularmente verdadeiro para usuários que hesitam em manter seu próprio software construído fora do esquema de empacotamento padrão de sua distribuição. Embora a maioria dos pacotes das distribuições inclua os módulos mais usados, se você precisar de um módulo não padrão, terá que construir o servidor a partir do código-fonte.

Os módulos NGINX, por outro lado, ainda são bastante valiosos, pois permitem especificar exatamente o que você deseja do seu servidor, incluindo apenas os recursos que deseja usar. Alguns usuários também podem acreditar que essa abordagem é mais segura porque componentes arbitrários não podem ser conectados ao servidor. Se o seu servidor for colocado em uma situação em que isso seja concebível, é quase certo que ele já esteja comprometido.

Muitos dos mesmos recursos estão disponíveis nos módulos NGINX e nos módulos Apache. Suporte de proxy, compactação, restrição de taxa, registro, regravação, geolocalização, autenticação, criptografia, streaming e funções de correio estão todos disponíveis por meio dos módulos NGINX.

Suporte, Compatibilidade, Ecossistema e documentação

O NGINX está ganhando popularidade à medida que mais pessoas o usam por causa de seu alto desempenho, mas ainda tem que se atualizar em certas áreas cruciais.

Como a maior parte do desenvolvimento inicial e da documentação estava em russo, era difícil localizar documentação substancial em inglês para o NGINX no passado. A documentação foi aprimorada à medida que o interesse no projeto cresceu, e atualmente há muitos recursos de administração disponíveis no site NGINX e por meio de terceiros.

O suporte e a documentação para aplicativos de terceiros estão se tornando mais amplamente disponíveis e os mantenedores de pacotes estão começando a oferecer opções para configurar automaticamente o Apache e o NGINX em algumas circunstâncias. Configurar o NGINX para operar com outros softwares geralmente é simples mesmo sem suporte, desde que documentadas as necessidades do projeto (permissões, cabeçalhos, etc).

Vantagens do NGINX

O servidor web NGINX é simples, leve e rápido. Projetado especificamente para sites com alto tráfego.

• Usa uma arquitetura não bloqueante orientada a eventos que usa menos CPU e memória.
• Inclui muitas opções de otimização e veiculação de conteúdo estático. Como resultado, ele fornece conteúdo estático 2,5 vezes mais rápido e usa menos memória que o Apache.
• Tem um desempenho admirável em um sistema multiprocessador.
• Os ataques DDoS são evitados por uma opção de configuração integrada.

Desvantagens do NGINX

• O conteúdo dinâmico não pode ser processado nativamente.
• Um número menor de módulos está disponível.
• Os sistemas operacionais Linux e Unix são suportados, mas o suporte ao Windows é restrito.
• O arquivo .htaccess , que é suportado pelo Apache, não é suportado pelo NGINX.
• Uma escassez de software de monitoramento de log - Simplesmente salva logs em arquivos que devem ser navegados manualmente.

Para usar o Apache e o NGINX juntos

Depois de analisar as vantagens e desvantagens do Apache e do NGINX, você poderá determinar qual servidor é mais adequado às suas necessidades. Muitos usuários, no entanto, acham que usar os dois servidores juntos permite que eles aproveitem os benefícios de cada servidor.

A configuração padrão para essa cooperação é usar o NGINX como proxy reverso na frente do Apache. Isso permitirá que o NGINX processe todas as solicitações do cliente. Isso faz uso da velocidade de processamento rápido do NGINX e da capacidade de gerenciar um grande número de conexões de uma só vez.

Os arquivos serão servidos rapidamente e diretamente ao cliente para conteúdo estático, no qual o NGINX se destaca. O NGINX fará proxy de solicitações de conteúdo dinâmico, como scripts PHP, para o Apache, que processará os resultados e fornecerá a página renderizada. O material pode então ser devolvido ao cliente via NGINX.

Para muitos usuários, esse design funciona bem, pois permite que o NGINX atue como uma máquina de classificação. Ele lidará com quaisquer solicitações que puder e passará aquelas que não souber lidar. Podemos reduzir alguns dos bloqueios que ocorrem quando um processo ou thread do Apache é ocupado reduzindo o número de solicitações que o servidor Apache é solicitado a tratar.

Você pode expandir com esse arranjo adicionando mais servidores de back-end conforme necessário. O NGINX pode simplesmente ser configurado para encaminhar solicitações a um pool de servidores, melhorando a tolerância a falhas e o desempenho da configuração.

Quando usar Apache vs NGINX?

Tanto o Apache quanto o NGINX, conforme descrito neste artigo, são servidores web poderosos, adaptáveis ​​e em geral bons. Para sites de alto tráfego, o Apache é melhor para fornecer material dinâmico, enquanto o NGINX é melhor para fornecer conteúdo estático ou fluxos de mídia. É tão simples como isto:

Quando você pode usar o Apache

• Se você estiver em um plano de hospedagem compartilhada.
• Se você aprecia uma comunidade útil com muitos recursos, este é o lugar para você.
• O Apache é popular entre os desenvolvedores da Web porque é simples de configurar.

Quando você pode usar o NGINX

• Se você possui um VPS ou servidor dedicado.
• Você é o proprietário de um site popular com muito conteúdo estático.
• Se você deseja gerenciar o tráfego de entrada e distribuí-lo para servidores upstream que são mais lentos.

Apache vs. NGINX: Qual você deve escolher para o seu servidor em 2022?

Qualquer um que sua empresa de hospedagem forneça é o que você deve usar. Em muitas circunstâncias, você não terá uma opção. Muitos provedores da Web seguem a mesma estratégia, que você deve seguir se estiver decidindo entre Apache e NGINX:

• O Apache é uma boa escolha se você deseja hospedar um servidor que requer configuração constante ou se deseja dar aos usuários uma opção de configuração.
• O NGINX, por outro lado, é o caminho a percorrer se você deseja desempenho super-rápido, segurança sólida e capacidade de gerenciar configurações em vez de seus usuários.

Por causa de sua arquitetura fundamental, o Apache pode ocupar mais memória RAM em termos de desempenho. Em casos de tráfego intenso, o NGINX terá um desempenho melhor, especialmente se houver muito material estático para gerenciar.

O NGINX pode, portanto, ser a solução ideal se você confiar no cache para armazenar e fornecer conteúdo. Lembre-se de que o NGINX não pode fornecer material dinâmico; portanto, seu desempenho será afetado pela eficácia do proxy que seu servidor utiliza.

Conclusão

Como você pode ver, o Apache e o NGINX são poderosos, adaptáveis ​​e capazes. Avaliar suas necessidades individuais e testar os padrões que você espera ver são os principais critérios para selecionar o servidor certo para você.

Entre esses projetos, há diferenças significativas no desempenho bruto, nos recursos e no tempo necessário para implementar cada um. Muitas vezes, no entanto, eles são o resultado de uma série de trocas que não devem ser ignoradas. Por último, mas não menos importante, não existe um servidor web de tamanho único, portanto, escolha a opção que atenda às suas necessidades.