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.
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:
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.
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.
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:
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:
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.
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
.
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:
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:
ssl_session_cache
para armazenar em cache os parâmetros usados ao proteger cada nova conexão com 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 .
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.
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.
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:
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.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.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!
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:
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.proxy_buffer_size
e proxy_buffers
para gerenciá-lo.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.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 .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.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.reuseport
na diretiva listen
.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 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 .
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:
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.
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:
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!
Kissmetrics – Como o tempo de carregamento afeta seus resultados financeiros (infográfico)
"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."