10 dicas para aumentar em 10 vezes o desempenho de aplicações

Floyd SmithDiretor de Marketing de Conteúdo

Melhorar o desempenho de aplicações web é mais importante do que nunca. A parcela da atividade econômica realizada online está crescendo; mais de 5% da economia dos países desenvolvidos já está na Internet (consulte Recursos sobre estatísticas da Internet abaixo). Além disso, em nosso mundo moderno, sempre conectado e hiperconectado, as expectativas dos usuários estão mais altas do que nunca. Se o seu site não responder instantaneamente ou se o seu aplicativo não funcionar sem demora, os usuários rapidamente migrarão para os concorrentes.

Por exemplo, um estudo realizado pela Amazon há quase 10 anos comprovou que, mesmo naquela época, uma redução de 100 milissegundos no tempo de carregamento da página resultava em um aumento de 1% na receita da empresa. Outro estudo recente destacou que mais da metade dos proprietários de sites entrevistados afirmou ter perdido receita ou clientes devido ao baixo desempenho das aplicações.

Qual deve ser a velocidade de um site? A 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 até a primeira interação que varia de um a três segundos, o que proporciona a maior taxa de conversão. Está claro que o desempenho das aplicações web é um fator crítico e tende a se tornar ainda mais importante.

Querer melhorar o desempenho é fácil, mas obter resultados concretos é difícil. Para ajudar você nessa jornada, este post apresenta dez dicas que podem aumentar em até 10 vezes o desempenho do seu site. Este é o primeiro de uma série de artigos que explicam como melhorar o desempenho da sua aplicação com algumas técnicas de otimização comprovadas e um pouco de ajuda do NGINX. A série também aborda possíveis melhorias de segurança que você pode obter ao longo do caminho.

Dica 1 – Acelere e proteja aplicações com um servidor proxy reverso

Se a sua aplicação web for executada em uma única máquina, a solução para os problemas de desempenho pode parecer óbvia: basta adquirir uma máquina mais rápida, com mais capacidade de processamento, mais RAM, um conjunto de discos de alta velocidade e assim por diante. Assim, a nova máquina poderá executar seu servidor WordPress, sua aplicação Node.js, sua aplicação Java etc. mais rapidamente do que antes. (Se a sua aplicação acessar um servidor de banco de dados, a solução ainda poderá parecer simples: adquirir duas máquinas mais rápidas e uma conexão mais veloz entre elas.)

O problema é que a velocidade da máquina talvez não seja a causa. As aplicações web muitas vezes ficam lentas porque o computador alterna entre diferentes tipos de tarefas: interagir com usuários em milhares de conexões, acessar arquivos no disco e executar o código da aplicação, entre outras. O servidor de aplicações pode estar sobrecarregado — ficando sem memória, transferindo blocos de memória para o disco e fazendo com que muitas solicitações aguardem a conclusão de uma única tarefa, como uma operação de E/S de disco.

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

O uso de um servidor proxy reverso evita que o servidor de aplicações tenha que esperar que os usuários interajam com a aplicação web e permite que ele se concentre em criar páginas para o servidor proxy reverso enviar pela Internet. Como não precisa mais aguardar as respostas dos clientes, o servidor de aplicações pode operar em velocidades próximas às alcançadas em benchmarks otimizados.

Adicionar um servidor proxy reverso também torna a configuração do seu servidor web mais flexível. Por exemplo, se um servidor de determinado tipo estiver sobrecarregado, será fácil adicionar outro servidor do mesmo tipo; se um servidor estiver fora do ar, será fácil substituí-lo.

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

• Balanceamento de carga (consulte a Dica 2) – Um balanceador de carga é executado em um servidor proxy reverso para distribuir o tráfego uniformemente entre vários servidores de aplicativos. Com um balanceador de carga, você pode adicionar servidores de aplicativos sem precisar alterar seu aplicativo.
• Cache de arquivos estáticos (consulte a Dica 3) – Os arquivos solicitados diretamente, como arquivos de imagem ou de código, podem ser armazenados no servidor proxy reverso e enviados diretamente ao cliente, o que permite disponibilizar os recursos com mais rapidez e reduz a carga do servidor de aplicações, fazendo com que a aplicação seja executada mais rapidamente.
• Como proteger seu site – O servidor proxy reverso pode ser configurado com um alto nível de segurança e monitorado para detectar e responder rapidamente a ataques, mantendo os servidores de aplicativos protegidos.

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

Dica 2 – Adicione um balanceador de carga

Adicionar um balanceador de carga é uma mudança relativamente simples que pode melhorar drasticamente o desempenho e a segurança do seu site. Em vez de aumentar a capacidade e a potência de um servidor web principal, você usa um balanceador de carga para distribuir o tráfego entre vários servidores. Mesmo que uma aplicação tenha sido mal desenvolvida ou apresente problemas de escalabilidade, um balanceador de carga pode melhorar a experiência do usuário sem nenhuma outra alteração.

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

Os balanceadores de carga podem proporcionar melhorias significativas de desempenho, pois evitam que um servidor fique sobrecarregado enquanto outros aguardam tráfego. Eles também facilitam a expansão da capacidade dos servidores web, já que é possível adicionar servidores de custo relativamente baixo e ter a certeza de que serão plenamente utilizados.

Os protocolos que podem ter a carga balanceada incluem HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached e vários outros tipos de aplicações, incluindo aplicações baseadas em TCP e outros protocolos da Camada 4. Analise suas aplicações web para identificar quais deles você usa e onde há problemas de desempenho.

O mesmo servidor ou os mesmos servidores usados para balanceamento de carga também podem realizar várias outras tarefas, como terminação SSL, suporte ao HTTP/1.x e ao uso de HTTP/2 pelos clientes, além do armazenamento em cache de 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ê encontra instruções básicas de configuração em Balanceamento de carga com NGINX e NGINX Plus, Parte 1, e a documentação completa no Guia de Administração do NGINX Plus. O NGINX Plus é nosso produto comercial e oferece recursos mais especializados de balanceamento de carga, como o roteamento de carga com base no tempo de resposta do servidor e a capacidade de balancear a carga no protocolo NTLM da Microsoft.

Dica 3 – Armazene conteúdo estático e dinâmico em cache

O armazenamento em cache melhora o desempenho das aplicações web ao entregar conteúdo aos clientes com mais rapidez. Ele pode envolver várias estratégias: pré-processar o conteúdo para entrega rápida quando necessário, armazená-lo em dispositivos mais rápidos, mantê-lo mais próximo do cliente ou combinar essas abordagens.

Há dois tipos diferentes de cache a serem considerados:

• 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 – Muitas aplicações Web geram um novo HTML para cada solicitação de página. Ao armazenar temporariamente em cache uma cópia do HTML gerado, você pode reduzir drasticamente o número total de páginas que precisam ser geradas e, ao mesmo tempo, fornecer conteúdo atualizado o suficiente para atender aos seus requisitos.

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

Há três técnicas principais para armazenar em cache o conteúdo gerado por aplicações web:

• Aproximar o conteúdo dos usuários – Manter uma cópia do conteúdo mais próxima do usuário reduz o tempo de transmissão.
• Mover o conteúdo para máquinas mais rápidas – O conteúdo pode ser mantido em uma máquina mais rápida para agilizar sua recuperação.
• Transferência de conteúdo de máquinas sobrecarregadas – Às vezes, as máquinas executam uma tarefa específica muito mais lentamente do que seu desempenho de referência porque estão ocupadas com outras tarefas. O armazenamento em cache em outra máquina melhora o desempenho tanto dos recursos armazenados em cache quanto dos que não estão, pois reduz a sobrecarga da máquina host.

O cache para aplicações web pode ser implementado de dentro para fora, começando pelo servidor da aplicação web. Primeiro, o cache é usado para conteúdo dinâmico, a fim de reduzir a carga nos servidores de aplicações. Em seguida, ele é 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 desses servidores. Por fim, o cache é transferido dos servidores de aplicações para máquinas mais rápidas e/ou mais próximas do usuário, reduzindo a carga nos servidores de aplicações, bem como os tempos de recuperação e transmissão.

Um cache aprimorado pode acelerar enormemente as aplicações. Em muitas páginas da web, dados estáticos, como arquivos de imagem grandes, representam mais da metade do conteúdo. Sem cache, a recuperação e a transmissão desses dados podem levar vários segundos, mas apenas frações de segundo se eles estiverem 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 a localização e o tamanho do cache, o tempo máximo durante o qual os arquivos são mantidos nele e outros parâmetros. Usando uma terceira diretiva (bastante popular), proxy_cache_use_stale, você pode até mesmo instruir o cache a fornecer conteúdo desatualizado quando o servidor que fornece conteúdo atualizado estiver ocupado ou indisponível, oferecendo ao cliente alguma coisa em vez de nada. Do ponto de vista do usuário, isso pode melhorar significativamente a disponibilidade do seu site ou aplicativo.

NGINX Plus tem recursos avançados de cache, incluindo suporte à limpeza do cache e visualização do status do cache em um painel para monitoramento da atividade em tempo real.

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

Observação: O armazenamento em cache ultrapassa as fronteiras organizacionais entre as pessoas que desenvolvem aplicativos, as que tomam decisões de investimento de capital e as que operam redes em tempo real. Estratégias sofisticadas de armazenamento em cache, como as mencionadas aqui, são um bom exemplo do valor de uma perspectiva DevOps, na qual as perspectivas de desenvolvimento de aplicativos, arquitetura e operações são integradas 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 – Compacte os dados

A compactação tem um enorme potencial para acelerar o desempenho. Existem padrões de compactação cuidadosamente desenvolvidos e altamente eficazes para fotos (JPEG e PNG), vídeos (MPEG‑4) e músicas (MP3), entre outros. Cada um desses padrões reduz o tamanho dos arquivos em dez vezes ou mais.

Dados de texto – incluindo HTML (que contém texto simples e tags HTML), CSS e código como JavaScript – muitas vezes são transmitidos sem compactação. A compactação desses dados pode ter um impacto desproporcional no desempenho percebido de aplicações 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 o usuário interaja com uma página, enquanto os dados multimídia podem ter uma função mais complementar ou decorativa. 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ê usa SSL, a compactação reduz a quantidade de dados que precisam ser codificados com SSL, compensando parte do tempo de CPU necessário para compactá-los.

Os métodos de compactação de dados de texto variam. Por exemplo, consulte a Dica 6 para conhecer um novo esquema de compactação de texto no SPDY e no 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 os dados de texto nos seus serviços, você pode disponibilizar diretamente o arquivo compactado .gz usando a diretiva gzip_static.

Dica 5 – Otimize o 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. O SSL/TLS criptografa os dados transmitidos dos servidores de origem aos usuários, ajudando a aumentar a segurança do site. Um dos fatores que podem estar impulsionando essa tendência é o fato de que o Google agora considera a presença de SSL/TLS um fator positivo para o posicionamento nos mecanismos de busca.

Apesar da crescente popularidade, o impacto do SSL/TLS no desempenho ainda é um obstáculo para muitos sites. O SSL/TLS reduz o desempenho dos sites por dois motivos:

1. O handshake inicial necessário para estabelecer as chaves de criptografia sempre que uma nova conexão é aberta. A forma como os navegadores que usam HTTP/1.x estabelecem várias conexões por servidor multiplica esse impacto.
2. Sobrecarga contínua decorrente da criptografia dos dados no servidor e da 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 significativamente uma das duas principais fontes de sobrecarga do SSL. No entanto, ainda é possível fazer mais para melhorar o desempenho das aplicações fornecidas por SSL/TLS.

O mecanismo de otimização de SSL/TLS varia de acordo com o servidor web. Por exemplo, o NGINX usa o OpenSSL, executado em hardware padrão disponível no mercado, para oferecer desempenho semelhante ao de soluções de hardware dedicadas. O desempenho de SSL do NGINX é bem documentado e minimiza o tempo e o uso de CPU necessários para realizar a criptografia e a descriptografia SSL/TLS.

Além disso, consulte esta publicação no blog para obter detalhes sobre como melhorar o desempenho de SSL/TLS. Em resumo, 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.
• Tíquetes ou IDs de sessão – Eles armazenam informações sobre sessões SSL/TLS específicas em um tíquete ou ID, permitindo que uma conexão seja reutilizada sem interrupções e sem um novo handshake.
• Grampeamento OCSP – Reduz o tempo de handshake armazenando em cache as informações do certificado SSL/TLS.

O NGINX e o NGINX Plus podem ser usados para terminação SSL/TLS, processando a criptografia e a descriptografia do tráfego de clientes enquanto se comunicam com outros servidores em texto não criptografado. Para configurar o NGINX ou o NGINX Plus para realizar 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, é muito provável que o HTTP/2 e o SPDY melhorem o desempenho, pois a conexão única exige apenas um handshake. Para sites que ainda não usam SSL/TLS, o HTTP/2 e o SPDY compensam a migração para SSL/TLS (que normalmente reduz o desempenho) do ponto de vista da capacidade de resposta.

O Google introduziu o SPDY em 2012 como uma forma de obter um desempenho mais rápido sobre o HTTP/1.x. O HTTP/2 é o padrão da IETF recentemente aprovado e baseado no SPDY. O SPDY é amplamente compatível, 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 várias conexões. Essa conexão é multiplexada, portanto pode transportar partes de várias solicitações e respostas ao mesmo tempo.

Ao aproveitar ao máximo uma única conexão, esses protocolos evitam a sobrecarga de estabelecer e gerenciar várias conexões, como exige a forma como os navegadores implementam o HTTP/1.x. O uso de uma única conexão é especialmente vantajoso com SSL, pois minimiza o demorado processo de negociação necessário para que o SSL/TLS estabeleça uma conexão segura.

O protocolo SPDY exigia o uso de SSL/TLS; o HTTP/2 não o exige oficialmente, mas, até o momento, todos os navegadores compatíveis com HTTP/2 só o utilizam se o SSL/TLS estiver habilitado. Ou seja, um navegador compatível com HTTP/2 só o utiliza se o site estiver usando SSL e seu servidor aceitar tráfego HTTP/2. Caso contrário, o navegador se comunica por HTTP/1.x.

Ao implementar SPDY ou HTTP/2, você não precisa mais das otimizações de desempenho típicas do HTTP, como fragmentação de domínio, combinação de recursos e uso de sprites de imagens. Essas mudanças simplificam seu código e suas implantações, facilitando o gerenciamento. Para saber mais sobre as mudanças trazidas pelo HTTP/2, leia nosso white paper, HTTP/2 para desenvolvedores de aplicações web.

Como exemplo de compatibilidade com esses protocolos, o NGINX oferece suporte ao SPDY desde o início, e a maioria dos sites que usam SPDY atualmente é executada no NGINX. O NGINX também está na vanguarda do suporte ao HTTP/2, com suporte ao HTTP/2 no NGINX de código aberto e no NGINX Plus desde setembro de 2015.

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

Dica 7 – Atualize as versões dos softwares

Uma maneira simples de melhorar o desempenho dos aplicativos é selecionar os componentes da sua pilha de software com base na reputação deles em termos de estabilidade e desempenho. Além disso, como os desenvolvedores de componentes de alta qualidade tendem a aprimorar o desempenho e corrigir bugs ao longo do tempo, vale a pena usar a versão estável mais recente do software. Novas versões recebem mais atenção dos desenvolvedores e da comunidade de usuários. Compilações mais recentes também aproveitam novas otimizações do compilador, incluindo ajustes para novos hardwares.

Novas versões estáveis geralmente oferecem maior compatibilidade e desempenho do que versões mais antigas. Também é mais fácil acompanhar otimizações de desempenho, correções de bugs e alertas de segurança quando você mantém o software atualizado.

Continuar usando softwares mais antigos também pode impedir que você aproveite 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 do NGINX Plus; eles incluem novos recursos, como fragmentação de sockets e pools de threads (consulte a Dica 9), e ambos são constantemente otimizados para melhorar o desempenho. Em seguida, analise os softwares nas camadas mais profundas da sua pilha e migre para a versão mais recente sempre que possível.

Dica 8 – Ajuste o Linux para melhorar o desempenho

O Linux é o sistema operacional subjacente à maioria das implementações de servidores web atuais e, como base da sua infraestrutura, oferece uma oportunidade significativa de melhorar o desempenho. Por padrão, muitos sistemas Linux são configurados de forma conservadora para usar poucos recursos e atender a uma carga de trabalho típica de desktop. Isso significa que os casos de uso de aplicações web exigem pelo menos algum nível de ajuste para alcançar o desempenho máximo.

As otimizações do Linux são específicas para cada servidor web. Usando o NGINX como exemplo, veja alguns dos principais ajustes que você pode considerar para acelerar o Linux:

• Fila de conexões pendentes – Se houver conexões que parecem estar travadas, considere aumentar net.core.somaxconn, o número máximo de conexões que podem ficar na fila aguardando processamento pelo NGINX. Você verá mensagens de erro se o limite de conexões atual for muito baixo e poderá aumentar esse parâmetro gradualmente até que as mensagens de erro parem de aparecer.
• 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 de descritores de arquivo de todo o sistema, e nofile, o limite de descritores de arquivo do usuário, para comportar o aumento da carga.
• Portas efêmeras – Quando usado como proxy, o NGINX cria portas temporárias (“efêmeras”) para cada servidor upstream. Você pode ampliar o intervalo de valores de porta, definido por net.ipv4.ip_local_port_range, para aumentar o número de portas disponíveis. Também é possível 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 saber como otimizar seu sistema Linux para que ele possa lidar com grandes volumes de tráfego de rede sem nenhum esforço!

Dica 9 – Ajuste seu servidor web para melhorar o desempenho

Independentemente do servidor web que você usa, é necessário ajustá-lo para melhorar o desempenho das aplicações web. As recomendações a seguir se aplicam, de modo geral, a qualquer servidor web, mas são fornecidas configurações específicas para o NGINX. As principais otimizações incluem:

• Registro de acesso – Em vez de gravar imediatamente no disco uma entrada de log para cada solicitação, você pode armazenar as entradas temporariamente na memória e gravá-las no disco em conjunto. No NGINX, adicione o parâmetro buffer=size à diretiva access_log para gravar as 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 especificado.
• Bufferização – A bufferização mantém parte de uma resposta na memória até que o buffer fique cheio, o que pode tornar a comunicação com o cliente mais eficiente. As respostas que não cabem na memória são gravadas em disco, o que pode reduzir o desempenho. Quando a bufferização do NGINX está ativada, use as diretivas proxy_buffer_size e proxy_buffers para gerenciá-la.
• Keepalives do cliente – As conexões keepalive reduzem a sobrecarga, especialmente quando SSL/TLS está em uso. No NGINX, você pode aumentar o número máximo de solicitações keepalive_requests que um cliente pode fazer em uma determinada conexão, em relação ao valor padrão de 100, e pode aumentar o keepalive_timeout para permitir que a conexão keepalive permaneça aberta por mais tempo, agilizando as solicitações subsequentes.
• Keepalives de upstream – As conexões de upstream – conexões com servidores de aplicativos, servidores de banco de dados e assim por diante – também se beneficiam das conexões keepalive. Para conexões de upstream, você pode aumentar keepalive, o número de conexões keepalive ociosas que permanecem abertas para cada processo worker. Isso permite aumentar a reutilização de conexões, reduzindo a necessidade de abrir conexões totalmente novas. Para obter mais informações, consulte nossa publicação no blog, Conexões HTTP keepalive e desempenho da Web.
• Limites – Limitar os recursos usados pelos clientes pode melhorar o desempenho e a segurança. No NGINX, as diretivas limit_conn e limit_conn_zone restringem o número de conexões de uma determinada origem, enquanto limit_rate limita a largura de banda. Essas configurações podem impedir que um usuário legítimo monopolize os recursos e também ajudam a evitar ataques. As diretivas limit_req e limit_req_zone limitam as solicitações dos clientes. Para conexões com servidores upstream, use o parâmetro max_conns da diretiva server em um bloco de configuração upstream. Isso limita as conexões com um servidor upstream, evitando sobrecarga. A diretiva queue associada cria uma fila que retém um número especificado de solicitações por um período determinado após o limite de max_conns ser atingido.
• Processos de trabalho – Os processos de trabalho são responsáveis pelo processamento das solicitações. O NGINX utiliza um modelo baseado em eventos e mecanismos dependentes do sistema operacional para distribuir com eficiência as solicitações entre os processos de trabalho. Recomenda-se 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; faça testes para encontrar o valor mais adequado ao seu sistema.
• Fragmentação de soquetes – Normalmente, um único soquete de escuta distribui novas conexões entre todos os processos de trabalho. A fragmentação de soquetes cria um soquete de escuta para cada processo de trabalho, e o kernel atribui as conexões aos soquetes de escuta à medida que eles ficam disponíveis. Isso pode reduzir a contenção de bloqueios e melhorar o desempenho em sistemas com vários núcleos. Para habilitar a fragmentação de soquetes, inclua o parâmetro reuseport na diretiva listen.
• Pools de threads – Qualquer processo de computador pode ser interrompido por uma única operação lenta. Em um software de servidor web, o acesso ao disco pode atrasar muitas operações 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 as operações mais rápidas. Quando a operação de 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.

Dica. Ao alterar as configurações de qualquer sistema operacional ou serviço de suporte, altere apenas uma configuração por vez e, em seguida, teste o desempenho. Se a alteração causar problemas ou não deixar seu site mais rápido, desfaça-a.

Para saber mais sobre como otimizar um servidor web NGINX, confira nosso post no blog, Otimizando o NGINX para melhorar o desempenho.

Dica 10 – Monitore a atividade em tempo real para resolver problemas e gargalos

A chave para uma abordagem de alto desempenho no desenvolvimento e na entrega de aplicações é acompanhar de perto e em tempo real o desempenho da sua aplicação no mundo real. Você deve ser capaz de monitorar a atividade 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ê a tarefa de identificar e corrigir os problemas.

O monitoramento pode detectar vários tipos de problemas, incluindo:

• Um servidor está fora do ar.
• Um servidor está operando com dificuldades e perdendo conexões.
• Um servidor está apresentando uma alta proporção de falhas de cache.
• Um servidor não está enviando o conteúdo correto.

Uma ferramenta global de monitoramento de desempenho de aplicações, como o New Relic ou o Dynatrace, ajuda você a monitorar o tempo de carregamento das páginas a partir de locais remotos, enquanto o NGINX ajuda a monitorar a entrega da aplicação. Os dados de desempenho da aplicação mostram quando suas otimizações estão fazendo uma diferença real para os usuários e quando é necessário considerar a ampliação da capacidade da infraestrutura para comportar o tráfego.

Para ajudar a identificar e resolver problemas rapidamente, o NGINX Plus adiciona verificações de integridade com reconhecimento de aplicações – transações sintéticas que são repetidas regularmente e usadas para alertar você sobre problemas. O NGINX Plus também conta com drenagem de sessões, que interrompe novas conexões enquanto as tarefas existentes são concluídas, e com um recurso de inicialização lenta, que permite que um servidor recuperado retome gradualmente sua capacidade em um grupo com balanceamento de carga. Quando usadas de forma eficaz, as verificações de integridade permitem identificar problemas antes que afetem significativamente a experiência do usuário, enquanto a drenagem de sessões e a inicialização lenta permitem substituir servidores e garantir que o processo não afete negativamente o desempenho percebido nem o tempo de atividade. A figura mostra o painel integrado de monitoramento de atividades em tempo real do NGINX Plus para uma infraestrutura web com servidores, conexões TCP e armazenamento em cache.

Conclusão – Obtendo uma melhoria de 10 vezes no desempenho

As melhorias de desempenho possíveis para cada aplicação web variam enormemente, e os ganhos reais dependem do seu orçamento, do tempo que você pode investir e das lacunas na implementação atual. Então, como alcançar uma melhoria de desempenho de 10 vezes nas suas próprias aplicações?

Para ajudar você a avaliar o impacto potencial de cada otimização, apresentamos algumas indicações dos ganhos que podem ser obtidos com cada dica detalhada acima, embora os resultados certamente variem:

• Servidor proxy reverso e balanceamento de carga – A ausência de balanceamento de carga, ou um balanceamento inadequado, pode causar períodos de desempenho muito ruim. Adicionar um servidor proxy reverso, como o NGINX, pode evitar que as aplicações web alternem excessivamente entre a memória e o disco. O balanceamento de carga pode transferir o processamento de servidores sobrecarregados para outros disponíveis, além de facilitar o escalonamento. Essas mudanças podem resultar em uma melhoria drástica no desempenho, sendo possível alcançar facilmente um ganho de 10 vezes em comparação com os piores momentos da implementação atual, além de ganhos menores, porém significativos, no desempenho geral.
• Cache de conteúdo dinâmico e estático – Se você tem um servidor web sobrecarregado que também funciona como servidor de aplicações, é possível obter uma melhoria de até 10 vezes no desempenho durante os horários de pico apenas armazenando o conteúdo dinâmico em cache. O cache de arquivos estáticos também pode melhorar o desempenho em algumas vezes.
• Compactação de dados – O uso de formatos de compactação de arquivos de mídia, como JPEG para fotos, PNG para imagens, MPEG‑4 para vídeos e MP3 para arquivos de áudio, pode melhorar significativamente o desempenho. Depois que todos eles estiverem em uso, a compactação de dados de texto (código e HTML) poderá reduzir pela metade o tempo de carregamento inicial da página.
• Otimização de SSL/TLS – Os handshakes seguros podem ter um grande impacto no desempenho. Portanto, otimizá-los pode resultar em uma melhoria de até 2 vezes na capacidade de resposta inicial, especialmente em sites com muito texto. A otimização da transmissão de arquivos de mídia por SSL/TLS provavelmente proporcionará apenas pequenas melhorias de desempenho.
• Implementação de HTTP/2 e SPDY – Quando usados com SSL/TLS, esses protocolos provavelmente resultarão em melhorias graduais no desempenho geral do site.
• Ajuste do Linux e do software do servidor web (como o NGINX) – Medidas como otimizar o uso de buffers, usar conexões keepalive e transferir tarefas demoradas para um pool de threads separado podem melhorar significativamente o desempenho; os pools de threads, por exemplo, podem acelerar tarefas que fazem uso intensivo do disco em quase uma ordem de grandeza.

Esperamos que você experimente essas técnicas. Queremos saber que tipo de melhoria no desempenho da aplicação você conseguiu alcançar. Compartilhe seus resultados nos comentários abaixo ou conte sua experiência no Twitter usando as hashtags #NGINX e #webperf!

Recursos sobre 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

Sobre o autor

Floyd SmithDiretor de Marketing de Conteúdo

Mais publicações de Floyd Smith