BLOG | NGINX

10 dicas para um desempenho de aplicativo 10x maior

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Floyd Smith
Floyd Smith
Publicado em 05 de outubro de 2015

Melhorar o desempenho dos aplicativos web é mais crítico do que nunca. A parcela da atividade econômica on-line está crescendo; mais de 5% da economia do mundo desenvolvido está agora na Internet (veja Recursos para Estatísticas da Internet abaixo). E nosso mundo moderno, sempre ativo e hiperconectado, significa que as expectativas dos usuários estão maiores do que nunca. Se o seu site não responder instantaneamente, ou se o seu aplicativo não funcionar imediatamente, os usuários rapidamente migram para seus concorrentes.

Por exemplo, um estudo realizado pela Amazon há quase 10 anos provou que, mesmo naquela época, uma redução de 100 milissegundos no tempo de carregamento da página se traduzia em um aumento de 1% em sua receita. Outro estudo recente destacou o fato de que mais da metade dos proprietários de sites pesquisados disseram que perderam receita ou clientes devido ao baixo desempenho dos aplicativos.

Quão rápido um site precisa ser? Para cada segundo que uma página leva para carregar, cerca de 4% dos usuários a abandonam. Os principais sites de comércio eletrônico oferecem um tempo para a primeira interação que varia de um a três segundos, o que oferece a maior taxa de conversão. É claro que as apostas para o desempenho de aplicativos da web são altas e provavelmente crescerão.

Querer melhorar o desempenho é fácil, mas ver resultados de fato é difícil. Para ajudar você em sua jornada, esta postagem do blog oferece dez dicas para ajudar a aumentar o desempenho do seu site em até 10x. É o primeiro de uma série que detalha como você pode aumentar o desempenho do seu aplicativo com a ajuda de algumas técnicas de otimização bem testadas e com um pouco de suporte do NGINX. Esta série também descreve potenciais melhorias em segurança que você pode obter ao longo do caminho.

Dica 1 – Acelere e proteja aplicativos com um servidor proxy reverso

Se seu aplicativo web for executado em uma única máquina, a solução para problemas de desempenho pode parecer óbvia: basta obter uma máquina mais rápida, com mais processador, mais RAM, um conjunto de discos rápido e assim por diante. Então a nova máquina poderá executar seu servidor WordPress, aplicativo Node.js, aplicativo Java, etc., mais rápido do que antes. (Se seu aplicativo acessa um servidor de banco de dados, a solução ainda pode parecer simples: obter duas máquinas mais rápidas e uma conexão mais rápida entre elas.)

O problema é que a velocidade da máquina pode não ser o problema. Os aplicativos da Web geralmente são executados lentamente porque o computador alterna entre diferentes tipos de tarefas: interagir com usuários em milhares de conexões, acessar arquivos do disco e executar código do aplicativo, entre outros. O servidor de aplicativos pode estar sobrecarregado – ficando sem memória, trocando pedaços de memória para o disco e fazendo muitas solicitações esperarem em uma única tarefa, como E/S de disco.

Em vez de atualizar seu hardware, você pode adotar uma abordagem totalmente diferente: adicionar um servidor proxy reverso para aliviar algumas dessas tarefas. Um servidor proxy reverso fica na frente da máquina que executa o aplicativo e lida com o tráfego da Internet. Somente o servidor proxy reverso é conectado diretamente à Internet; a comunicação com os servidores de aplicativos é feita por meio de uma rede interna rápida.

Usar um servidor proxy reverso libera o servidor de aplicativos de ter que esperar que os usuários interajam com o aplicativo web e permite que ele se concentre na criação de páginas para o servidor proxy reverso enviar pela Internet. O servidor de aplicativos, que não precisa mais esperar por respostas do cliente, pode ser executado em velocidades próximas às alcançadas em benchmarks otimizados.

Adicionar um servidor proxy reverso também adiciona flexibilidade à configuração do seu servidor web. Por exemplo, se um servidor de um determinado tipo estiver sobrecarregado, outro servidor do mesmo tipo pode ser facilmente adicionado; se um servidor estiver inativo, ele pode ser facilmente substituído.

Devido à flexibilidade que ele oferece, um servidor proxy reverso também é um pré-requisito para muitos outros recursos de aumento de desempenho, como:

  • Balanceamento de carga (veja a Dica 2 ) – Um balanceador de carga é executado em um servidor proxy reverso para compartilhar o tráfego uniformemente entre vários servidores de aplicativos. Com um balanceador de carga em funcionamento, você pode adicionar servidores de aplicativos sem alterar seu aplicativo.
  • Armazenando em cache arquivos estáticos (veja a Dica 3 ) – Arquivos que são solicitados diretamente, como arquivos de imagem ou arquivos de código, podem ser armazenados no servidor proxy reverso e enviados diretamente ao cliente, o que atende os ativos mais rapidamente e alivia o servidor de aplicativos, permitindo que o aplicativo seja executado mais rapidamente.
  • Protegendo seu site – O servidor proxy reverso pode ser configurado para alta segurança e monitorado para rápido reconhecimento e resposta a ataques, mantendo os servidores de aplicativos protegidos.

O software NGINX foi projetado especificamente para uso como um servidor proxy reverso, com os recursos adicionais descritos acima. O NGINX usa uma abordagem de processamento orientada a eventos que é mais eficiente do que servidores tradicionais. O NGINX Plus adiciona recursos de proxy reverso mais avançados, como verificações de integridade de aplicativos, roteamento de solicitações especializado, cache avançado e suporte.

Dica 2 – Adicione um balanceador de carga

Adicionar um balanceador de carga é uma mudança relativamente fácil que pode criar uma melhoria drástica no desempenho e na segurança do seu site. Em vez de tornar um servidor web principal maior e mais poderoso, você usa um balanceador de carga para distribuir o tráfego entre vários servidores. Mesmo que um aplicativo seja mal escrito ou tenha problemas de dimensionamento, um balanceador de carga pode melhorar a experiência do usuário sem nenhuma outra alteração.

Um balanceador de carga é, primeiro, um servidor proxy reverso (veja a Dica 1 ) – ele recebe tráfego da Internet e encaminha solicitações para outro servidor. O truque é que o balanceador de carga oferece suporte a dois ou mais servidores de aplicativos, usando uma variedade de algoritmos para dividir solicitações entre os servidores. A abordagem mais simples de balanceamento de carga é o round robin, com cada nova solicitação enviada para o próximo servidor na lista. Outros métodos incluem o envio de solicitações ao servidor com menos conexões ativas. O NGINX Plus tem recursos para continuar uma determinada sessão de usuário no mesmo servidor, o que é chamado de persistência de sessão.

Os balanceadores de carga podem levar a grandes melhorias no desempenho porque evitam que um servidor fique sobrecarregado enquanto outros servidores aguardam tráfego. Eles também facilitam a expansão da capacidade do seu servidor web, pois você pode adicionar servidores de custo relativamente baixo e ter certeza de que eles serão totalmente utilizados.

Os protocolos que podem ter balanceamento de carga incluem HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI , SCGI, uwsgi, memcached e vários outros tipos de aplicativos, incluindo aplicativos baseados em TCP e outros protocolos da Camada 4. Analise seus aplicativos web para determinar quais você usa e onde o desempenho está abaixo do esperado.

O mesmo servidor ou servidores usados para balanceamento de carga também podem lidar com diversas outras tarefas, como terminação SSL, suporte para uso de HTTP/1. x e HTTP/2 por clientes e armazenamento em cache para arquivos estáticos.

O NGINX é frequentemente usado para balanceamento de carga. Para saber mais, baixe nosso e-book, Cinco motivos para escolher um balanceador de carga de software . Você pode obter instruções básicas de configuração em Balanceamento de carga com NGINX e NGINX Plus, Parte 1 , e documentação completa no Guia de administração do NGINX Plus . O NGINX Plus é nosso produto comercial e oferece suporte a recursos de balanceamento de carga mais especializados, como roteamento de carga com base no tempo de resposta do servidor e a capacidade de balanceamento de carga no protocolo NTLM da Microsoft.

Dica 3 – Cache de conteúdo estático e dinâmico

O cache melhora o desempenho dos aplicativos web ao entregar conteúdo aos clientes mais rapidamente. O armazenamento em cache pode envolver várias estratégias: pré-processamento de conteúdo para entrega rápida quando necessário, armazenamento de conteúdo em dispositivos mais rápidos, armazenamento de conteúdo mais próximo do cliente ou uma combinação.

Há dois tipos diferentes de cache a serem considerados:

  • Armazenamento em cache de conteúdo estático – Arquivos que mudam com pouca frequência, como arquivos de imagem (JPEG, PNG) e arquivos de código (CSS, JavaScript), podem ser armazenados em um servidor de borda para recuperação rápida da memória ou do disco.
  • Cache de conteúdo dinâmico – Muitos aplicativos da Web geram HTML novo para cada solicitação de página. Ao armazenar em cache uma cópia do HTML gerado por um breve período de tempo, você pode reduzir drasticamente o número total de páginas que precisam ser geradas e, ao mesmo tempo, fornecer conteúdo novo o suficiente para atender às suas necessidades.

Se uma página recebe 10 visualizações por segundo, por exemplo, e você a armazena em cache por 1 segundo, 90% das solicitações da página virão do cache. Se você armazenar em cache separadamente o conteúdo estático, mesmo as versões recém-geradas da página poderão ser compostas em grande parte de conteúdo armazenado em cache.

Existem três técnicas principais para armazenar em cache o conteúdo gerado por aplicativos da web:

  • Movendo o conteúdo para mais perto dos usuários – Manter uma cópia do conteúdo mais perto do usuário reduz seu tempo de transmissão.
  • Movendo conteúdo para máquinas mais rápidas – O conteúdo pode ser mantido em uma máquina mais rápida para recuperação mais rápida.
  • Movendo conteúdo de máquinas sobrecarregadas – Às vezes, as máquinas operam muito mais lentamente do que seu desempenho de referência em uma tarefa específica porque estão ocupadas com outras tarefas. O armazenamento em cache em uma máquina diferente melhora o desempenho dos recursos armazenados em cache e também dos recursos não armazenados em cache, porque a máquina host fica menos sobrecarregada.

O cache para aplicativos da web pode ser implementado de dentro para fora – do servidor de aplicativos da web. Primeiro, o cache é usado para conteúdo dinâmico, para reduzir a carga nos servidores de aplicativos. Em seguida, o cache é usado para conteúdo estático (incluindo cópias temporárias do que, de outra forma, seria conteúdo dinâmico), aliviando ainda mais a carga dos servidores de aplicativos. E o armazenamento em cache é então movido dos servidores de aplicativos para máquinas mais rápidas e/ou mais próximas do usuário, aliviando os servidores de aplicativos e reduzindo os tempos de recuperação e transmissão.

O cache aprimorado pode acelerar os aplicativos tremendamente. Para muitas páginas da web, dados estáticos, como grandes arquivos de imagem, compõem mais da metade do conteúdo. Pode levar vários segundos para recuperar e transmitir esses dados sem armazenamento em cache, mas apenas frações de segundo se os dados forem armazenados em cache localmente.

Como exemplo de como o cache é usado na prática, o NGINX e o NGINX Plus usam duas diretivas para configurar o cache : proxy_cache_path e proxy_cache . Você especifica o local e o tamanho do cache, o tempo máximo que os arquivos são mantidos no cache e outros parâmetros. Usando uma terceira (e bastante popular) diretiva, proxy_cache_use_stale , você pode até mesmo direcionar o cache para fornecer conteúdo obsoleto quando o servidor que fornece conteúdo novo estiver ocupado ou inativo, dando ao cliente algo em vez de nada. Da perspectiva do usuário, isso pode melhorar muito o tempo de atividade do seu site ou aplicativo.

O NGINX Plus possui recursos avançados de cache , incluindo suporte para limpeza de cache e visualização do status do cache em um painel para monitoramento de atividades ao vivo.

Para obter mais informações sobre armazenamento em cache com o NGINX, consulte a documentação de referência e o Guia de administração do NGINX Plus .

Observação : O cache cruza as linhas organizacionais entre pessoas que desenvolvem aplicativos, pessoas que tomam decisões de investimento de capital e pessoas que administram redes em tempo real. Estratégias sofisticadas de cache, como as mencionadas aqui, são um bom exemplo do valor de uma perspectiva DevOps , na qual as perspectivas do desenvolvedor de aplicativos, da arquitetura e das operações são mescladas para ajudar a atingir metas de funcionalidade do site, tempo de resposta, segurança e resultados comerciais, como transações concluídas ou vendas.

Dica 4 – Comprimir dados

A compressão é um enorme potencial acelerador de desempenho. Existem padrões de compressão cuidadosamente projetados e altamente eficazes para fotos (JPEG e PNG), vídeos (MPEG‑4) e música (MP3), entre outros. Cada um desses padrões reduz o tamanho do arquivo em uma ordem de magnitude ou mais.

Dados de texto – incluindo HTML (que inclui texto simples e tags HTML), CSS e código como JavaScript – geralmente são transmitidos sem compactação. A compactação desses dados pode ter um impacto desproporcional no desempenho percebido do aplicativo web, especialmente para clientes com conexões móveis lentas ou limitadas.

Isso ocorre porque os dados de texto geralmente são suficientes para que um usuário interaja com uma página, enquanto os dados multimídia podem ser mais úteis ou decorativos. A compactação inteligente de conteúdo pode reduzir os requisitos de largura de banda de HTML, Javascript, CSS e outros conteúdos baseados em texto, normalmente em 30% ou mais, com uma redução correspondente no tempo de carregamento.

Se você usar SSL, a compactação reduzirá a quantidade de dados que precisam ser codificados em SSL, o que compensa parte do tempo de CPU necessário para compactar os dados.

Os métodos de compactação de dados de texto variam. Por exemplo, veja a Dica 6 para um novo esquema de compactação de texto em SPDY e HTTP/2, adaptado especificamente para dados de cabeçalho. Como outro exemplo de compactação de texto, você pode ativar a compactação GZIP no NGINX. Depois de pré-compactar dados de texto em seus serviços, você pode servir o arquivo .gz compactado diretamente usando a diretiva gzip_static .

Dica 5 – Otimize SSL/TLS

O protocolo Secure Sockets Layer ( SSL ) e seu sucessor, o protocolo Transport Layer Security (TLS), estão sendo usados em cada vez mais sites. SSL/TLS criptografa os dados transportados dos servidores de origem para os usuários para ajudar a melhorar a segurança do site. Parte do que pode estar influenciando essa tendência é que o Google agora usa a presença de SSL/TLS como uma influência positiva nas classificações dos mecanismos de busca.

Apesar da popularidade crescente, a queda de desempenho envolvida no SSL/TLS é um obstáculo para muitos sites. SSL/TLS diminui o desempenho do site por dois motivos:

  1. O handshake inicial necessário para estabelecer chaves de criptografia sempre que uma nova conexão é aberta. A maneira como os navegadores que usam HTTP/1. x estabelecem múltiplas conexões por servidor multiplica esse acerto.
  2. Sobrecarga contínua de criptografia de dados no servidor e descriptografia no cliente.

Para incentivar o uso de SSL/TLS, os autores do HTTP/2 e do SPDY (descritos na próxima Dica ) projetaram esses protocolos para que os navegadores precisem de apenas uma conexão por sessão. Isso reduz bastante uma das duas principais fontes de sobrecarga de SSL. No entanto, ainda mais pode ser feito hoje para melhorar o desempenho de aplicativos entregues por SSL/TLS.

O mecanismo para otimizar SSL/TLS varia de acordo com o servidor web. Como exemplo, o NGINX usa OpenSSL , executado em hardware padrão, para fornecer desempenho semelhante ao de soluções de hardware dedicadas. O desempenho do SSL do NGINX é bem documentado e minimiza o tempo e a perda de CPU causados pela criptografia e descriptografia SSL/TLS.

Além disso, consulte esta postagem do blog para obter detalhes sobre maneiras de aumentar o desempenho de SSL/TLS. Para resumir brevemente, as técnicas são:

  • Cache de sessão – Usa a diretiva ssl_session_cache para armazenar em cache os parâmetros usados ao proteger cada nova conexão com SSL/TLS.
  • Tickets ou IDs de sessão – Eles armazenam informações sobre sessões SSL/TLS específicas em um ticket ou ID para que uma conexão possa ser reutilizada sem problemas, sem novos handshakes.
  • Grampeamento OCSP – Reduz o tempo de handshake ao armazenar em cache as informações do certificado SSL/TLS.

NGINX e NGINX Plus podem ser usados para terminação SSL/TLS – manipulando criptografia e descriptografia para tráfego de cliente, enquanto se comunica com outros servidores em texto simples. Para configurar o NGINX ou o NGINX Plus para lidar com a terminação SSL/TLS, consulte as instruções para conexões HTTPS e conexões TCP criptografadas .

Dica 6 – Implemente HTTP/2 ou SPDY

Para sites que já usam SSL/TLS, HTTP/2 e SPDY provavelmente melhorarão o desempenho, porque a conexão única requer apenas um handshake. Para sites que ainda não usam SSL/TLS, HTTP/2 e SPDY fazem com que a mudança para SSL/TLS (que normalmente reduz o desempenho) seja um desastre do ponto de vista da capacidade de resposta.

O Google introduziu o SPDY em 2012 como uma forma de obter desempenho mais rápido no HTTP/1. x . HTTP/2 é o padrão IETF aprovado recentemente com base no SPDY. O SPDY tem amplo suporte, mas em breve será descontinuado e substituído pelo HTTP/2.

O principal recurso do SPDY e do HTTP/2 é o uso de uma única conexão em vez de múltiplas conexões. A conexão única é multiplexada, de modo que ela pode transportar partes de várias solicitações e respostas ao mesmo tempo.

Ao aproveitar ao máximo uma conexão, esses protocolos evitam a sobrecarga de configurar e gerenciar múltiplas conexões, conforme exigido pela maneira como os navegadores implementam o HTTP/1. x . O uso de uma única conexão é especialmente útil com SSL, porque minimiza o demorado handshake que o SSL/TLS precisa para configurar uma conexão segura.

O protocolo SPDY exigia o uso de SSL/TLS; o HTTP/2 não o exige oficialmente, mas todos os navegadores que suportam HTTP/2 o usam somente se o SSL/TLS estiver habilitado. Ou seja, um navegador que suporta HTTP/2 o utiliza somente se o site estiver usando SSL e seu servidor aceitar tráfego HTTP/2. Caso contrário, o navegador se comunica via HTTP/1. x .

Ao implementar SPDY ou HTTP/2, você não precisa mais de otimizações típicas de desempenho HTTP, como fragmentação de domínio, mesclagem de recursos e criação de imagens. Essas alterações tornam seu código e implantações mais simples e fáceis de gerenciar. Para saber mais sobre as mudanças que o HTTP/2 está trazendo, leia nosso white paper, HTTP/2 para desenvolvedores de aplicativos da Web .

Como exemplo de suporte para esses protocolos, o NGINX tem suportado o SPDY desde o início, e a maioria dos sites que usam o SPDY hoje rodam no NGINX. O NGINX também é pioneiro no suporte para HTTP/2, com suporte para HTTP/2 no NGINX open source e NGINX Plus a partir de setembro de 2015.

Com o tempo, nós da NGINX esperamos que a maioria dos sites habilite totalmente o SSL e migre para HTTP/2. Isso levará a uma maior segurança e, à medida que novas otimizações forem encontradas e implementadas, a um código mais simples e com melhor desempenho.

Dica 7 – Atualizar versões de software

Uma maneira simples de aumentar o desempenho do aplicativo é selecionar componentes para sua pilha de software com base em sua reputação de estabilidade e desempenho. Além disso, como os desenvolvedores de componentes de alta qualidade provavelmente buscarão melhorias de desempenho e corrigirão bugs ao longo do tempo, vale a pena usar a versão estável mais recente do software. Novos lançamentos recebem mais atenção dos desenvolvedores e da comunidade de usuários. Novas compilações também aproveitam as novas otimizações do compilador, incluindo ajustes para novo hardware.

Novos lançamentos estáveis geralmente são mais compatíveis e apresentam melhor desempenho do que lançamentos mais antigos. Também é mais fácil ficar por dentro das otimizações de ajuste, correções de bugs e alertas de segurança quando você fica por dentro das atualizações de software.

Continuar com softwares mais antigos também pode impedir que você aproveite os novos recursos. Por exemplo, o HTTP/2, descrito acima, atualmente requer o OpenSSL 1.0.1. A partir de meados de 2016, o HTTP/2 exigirá o OpenSSL 1.0.2, lançado em janeiro de 2015.

Os usuários do NGINX podem começar migrando para a versão mais recente do NGINX ou NGINX Plus ; eles incluem novos recursos, como fragmentação de soquetes e pools de threads (veja a Dica 9 ), e ambos estão sendo constantemente ajustados para desempenho. Em seguida, analise o software mais profundamente na sua pilha e vá para a versão mais recente sempre que possível.

Dica 8 – Ajuste o Linux para desempenho

O Linux é o sistema operacional subjacente para a maioria das implementações de servidores web hoje em dia e, como base da sua infraestrutura, representa uma oportunidade significativa para melhorar o desempenho. Por padrão, muitos sistemas Linux são ajustados de forma conservadora para usar poucos recursos e corresponder a uma carga de trabalho típica de desktop. Isso significa que os casos de uso de aplicativos web exigem pelo menos algum grau de ajuste para desempenho máximo.

As otimizações do Linux são específicas do servidor web. Usando o NGINX como exemplo, aqui estão alguns destaques de mudanças que você pode considerar para acelerar o Linux:

  • Fila de backlog – Se você tiver conexões que parecem estar travando, considere aumentar net.core.somaxconn , o número máximo de conexões que podem ser enfileiradas aguardando atenção do NGINX. Você verá mensagens de erro se o limite de conexão existente for muito pequeno, e você pode aumentar gradualmente esse parâmetro até que as mensagens de erro parem.
  • Descritores de arquivo – O NGINX usa até dois descritores de arquivo para cada conexão. Se o seu sistema estiver atendendo a muitas conexões, talvez seja necessário aumentar sys.fs.file_max , o limite do sistema para descritores de arquivo, e nofile , o limite do descritor de arquivo do usuário, para suportar o aumento de carga.
  • Portas efêmeras – Quando usado como proxy, o NGINX cria portas temporárias (“efêmeras”) para cada servidor upstream. Você pode aumentar o intervalo de valores de porta, definido por net.ipv4.ip_local_port_range , para aumentar o número de portas disponíveis. Você também pode reduzir o tempo limite antes que uma porta inativa seja reutilizada com a configuração net.ipv4.tcp_fin_timeout , permitindo uma rotatividade mais rápida.

Para o NGINX, confira o guia de ajuste de desempenho do NGINX para aprender como otimizar seu sistema Linux para que ele possa lidar com grandes volumes de tráfego de rede sem esforço algum!

Dica 9 – Ajuste seu servidor web para desempenho

Seja qual for o servidor web que você usar, você precisa ajustá-lo para o desempenho do aplicativo web. As recomendações a seguir se aplicam geralmente a qualquer servidor web, mas configurações específicas são fornecidas para NGINX. As principais otimizações incluem:

  • Registro de acesso – Em vez de gravar uma entrada de registro para cada solicitação no disco imediatamente, você pode armazenar entradas na memória e gravá-las no disco como um grupo. Para NGINX, adicione o parâmetro buffer= size à diretiva access_log para gravar entradas de log no disco quando o buffer de memória ficar cheio. Se você adicionar o parâmetro flush= time , o conteúdo do buffer também será gravado no disco após o período de tempo especificado.
  • Buffering – O buffer mantém parte de uma resposta na memória até que o buffer seja preenchido, o que pode tornar as comunicações com o cliente mais eficientes. As respostas que não cabem na memória são gravadas no disco, o que pode diminuir o desempenho. Quando o buffer do NGINX está ativado , você usa as diretivas proxy_buffer_size e proxy_buffers para gerenciá-lo.
  • Keepalives do cliente – As conexões Keepalive reduzem a sobrecarga, especialmente quando SSL/TLS está em uso. Para o NGINX, você pode aumentar o número máximo de keepalive_requests que um cliente pode fazer em uma determinada conexão do padrão de 100, e pode aumentar o keepalive_timeout para permitir que a conexão keepalive permaneça aberta por mais tempo, resultando em solicitações subsequentes mais rápidas.
  • Keepalives upstream – Conexões upstream – conexões com servidores de aplicativos, servidores de banco de dados e assim por diante – também se beneficiam de conexões keepalive. Para conexões upstream, você pode aumentar keepalive , o número de conexões keepalive ociosas que permanecem abertas para cada processo de trabalho. Isso permite maior reutilização de conexões, reduzindo a necessidade de abrir novas conexões. Para obter mais informações, consulte nossa postagem no blog, Conexões HTTP Keepalive e desempenho da Web .
  • Limites – Limitar os recursos que os clientes usam pode melhorar o desempenho e a segurança. Para NGINX, as diretivas limit_conn e limit_conn_zone restringem o número de conexões de uma determinada fonte, enquanto limit_rate restringe a largura de banda. Essas configurações podem impedir que um usuário legítimo “monopolize” recursos e também ajudar a prevenir ataques. As diretivas limit_req e limit_req_zone limitam as solicitações do cliente. Para conexões com servidores upstream, use o parâmetro max_conns na diretiva do servidor em um bloco de configuração upstream . Isso limita as conexões com um servidor upstream, evitando sobrecarga. A diretiva de fila associada cria uma fila que mantém um número especificado de solicitações por um período de tempo especificado após o limite max_conns ser atingido.
  • Processos de trabalho – Os processos de trabalho são responsáveis pelo processamento de solicitações. O NGINX emprega um modelo baseado em eventos e mecanismos dependentes do sistema operacional para distribuir solicitações de forma eficiente entre processos de trabalho. A recomendação é definir o valor de worker_processes como um por CPU. O número máximo de worker_connections (512 por padrão) pode ser aumentado com segurança na maioria dos sistemas, se necessário; experimente para encontrar o valor que funciona melhor para seu sistema.
  • Fragmentação de soquete – Normalmente, um único ouvinte de soquete distribui novas conexões para todos os processos de trabalho. A fragmentação de soquetes cria um ouvinte de soquete para cada processo de trabalho, com o kernel atribuindo conexões aos ouvintes de soquetes conforme eles se tornam disponíveis. Isso pode reduzir a contenção de bloqueio e melhorar o desempenho em sistemas multicore. Para habilitar o particionamento de soquete , inclua o parâmetro reuseport na diretiva listen .
  • Pools de threads – Qualquer processo de computador pode ser interrompido por uma única operação lenta. Para software de servidor web, o acesso ao disco pode realizar operações muito mais rápidas, como calcular ou copiar informações na memória. Quando um pool de threads é usado, a operação lenta é atribuída a um conjunto separado de tarefas, enquanto o loop de processamento principal continua executando operações mais rápidas. Quando a operação do disco é concluída, os resultados retornam ao loop de processamento principal. No NGINX, duas operações – a chamada de sistema read() e sendfile() – são transferidas para pools de threads .

Os pools de threads ajudam a aumentar o desempenho do aplicativo atribuindo uma operação lenta a um conjunto separado de tarefas

Dica . Ao alterar as configurações de qualquer sistema operacional ou serviço de suporte, altere uma única configuração por vez e depois teste o desempenho. Se a alteração causar problemas ou não fizer com que seu site fique mais rápido, altere-a novamente.

Para mais informações sobre como ajustar um servidor web NGINX, consulte nossa postagem no blog, Ajustando o NGINX para desempenho .

Dica 10 – Monitore a atividade ao vivo para resolver problemas e gargalos

A chave para uma abordagem de alto desempenho para desenvolvimento e entrega de aplicativos é observar de perto e em tempo real o desempenho do seu aplicativo no mundo real. Você deve ser capaz de monitorar atividades em dispositivos específicos e em toda a sua infraestrutura web.

O monitoramento da atividade do site é, em grande parte, passivo: ele informa o que está acontecendo e deixa para você identificar os problemas e corrigi-los.

O monitoramento pode detectar vários tipos diferentes de problemas. Eles incluem:

  • Um servidor está inativo.
  • Um servidor está lento, perdendo conexões.
  • Um servidor está sofrendo com uma alta proporção de perdas de cache.
  • Um servidor não está enviando conteúdo correto.

Uma ferramenta global de monitoramento de desempenho de aplicativos, como New Relic ou Dynatrace, ajuda você a monitorar o tempo de carregamento da página de locais remotos, enquanto o NGINX ajuda você a monitorar o lado da entrega do aplicativo. Os dados de desempenho do aplicativo informam quando suas otimizações estão fazendo uma diferença real para seus usuários e quando você precisa considerar adicionar capacidade à sua infraestrutura para sustentar o tráfego.

Para ajudar a identificar e resolver problemas rapidamente, o NGINX Plus adiciona verificações de integridade com reconhecimento de aplicativo – transações sintéticas que são repetidas regularmente e são usadas para alertá-lo sobre problemas. O NGINX Plus também possui drenagem de sessão , que interrompe novas conexões enquanto as tarefas existentes são concluídas, e um recurso de inicialização lenta, permitindo que um servidor recuperado ganhe velocidade dentro de um grupo com balanceamento de carga. Quando usadas de forma eficaz, as verificações de integridade permitem identificar problemas antes que eles afetem significativamente a experiência do usuário, enquanto o esgotamento da sessão e a inicialização lenta permitem substituir servidores e garantir que o processo não afete negativamente o desempenho percebido ou o tempo de atividade. A figura mostra o painel de monitoramento de atividades ao vivo do NGINX Plus integrado para uma infraestrutura web com servidores, conexões TCP e cache.

O painel NGINX Plus fornece estatísticas detalhadas para monitorar e gerenciar sua infraestrutura

Conclusão – Ver uma melhoria de desempenho de 10x

As melhorias de desempenho disponíveis para qualquer aplicativo web variam enormemente, e os ganhos reais dependem do seu orçamento, do tempo que você pode investir e das lacunas na sua implementação existente. Então, como você pode obter uma melhoria de desempenho de 10x em seus próprios aplicativos?

Para ajudar a orientá-lo sobre o impacto potencial de cada otimização, aqui estão algumas dicas sobre as melhorias que podem ser possíveis com cada dica detalhada acima, embora seu resultado quase certamente varie:

  • Servidor proxy reverso e balanceamento de carga – Nenhum balanceamento de carga ou balanceamento de carga ruim pode causar episódios de desempenho muito baixo. Adicionar um servidor proxy reverso, como o NGINX, pode evitar que aplicativos da web fiquem viajando entre a memória e o disco. O balanceamento de carga pode mover o processamento de servidores sobrecarregados para servidores disponíveis e facilitar o dimensionamento. Essas mudanças podem resultar em uma melhoria drástica no desempenho, com uma melhoria de 10x facilmente alcançada em comparação aos piores momentos da sua implementação atual, e conquistas menores, mas substanciais, disponíveis para o desempenho geral.
  • Armazenamento em cache de conteúdo dinâmico e estático – Se você tiver um servidor web sobrecarregado que também funciona como servidor de aplicativos, melhorias de 10x no desempenho em horários de pico podem ser obtidas armazenando em cache apenas conteúdo dinâmico. O armazenamento em cache de arquivos estáticos também pode melhorar o desempenho em múltiplos de um dígito.
  • Compactação de dados – Usar compactação de arquivos de mídia, como JPEG para fotos, PNG para gráficos, MPEG‑4 para filmes e MP3 para arquivos de música, pode melhorar muito o desempenho. Depois que tudo isso estiver em uso, a compactação de dados de texto (código e HTML) pode melhorar o tempo de carregamento inicial da página em um fator de dois.
  • Otimizando SSL/TLS – Handshakes seguros podem ter um grande impacto no desempenho, então otimizá-los pode levar a uma melhoria de talvez 2x na capacidade de resposta inicial, particularmente para sites com muito texto. Otimizar a transmissão de arquivos de mídia sob SSL/TLS provavelmente produzirá apenas pequenas melhorias de desempenho.
  • Implementação de HTTP/2 e SPDY – Quando usados com SSL/TLS, esses protocolos provavelmente resultarão em melhorias incrementais no desempenho geral do site.
  • Ajustar o software do servidor Linux e da Web (como NGINX) – Correções como otimizar o buffer, usar conexões keepalive e descarregar tarefas demoradas para um pool de threads separado podem aumentar significativamente o desempenho; os pools de threads, por exemplo, podem acelerar tarefas que exigem muito disco em quase uma ordem de magnitude .

Esperamos que você experimente essas técnicas. Queremos saber que tipo de melhorias no desempenho do aplicativo você consegue alcançar. Compartilhe seus resultados nos comentários abaixo ou tuíte sua história com as hashtags #NGINX e #webperf!

Recursos para Estatísticas da Internet

Statista.com – Participação da economia da Internet no produto interno bruto dos países do G‑20 em 2016

Kissmetrics – Como o tempo de carregamento afeta seus resultados financeiros (infográfico)

Econsultancy – Velocidade do site: estudos de caso, dicas e ferramentas para melhorar sua taxa de conversão


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."