Como reduzir a latência do servidor: 8 soluções que realmente funcionam

A latência é o atraso entre um pedido e a resposta. Para aplicações interativas, qualquer valor superior a 100 ms parece lento e, assim que se ultrapassam os 500 ms, os utilizadores começam a abandonar a página. Esta publicação aborda o que realmente causa a alta latência, oito técnicas para a reduzir e quais as que deve escolher, dependendo do seu orçamento e arquitetura.

O que causa a alta latência

Três fatores determinam quase toda a latência do servidor:

• Distância física. A luz viaja pela fibra a cerca de dois terços da velocidade no vácuo. Existe um limite mínimo para o tempo de ida e volta, determinado pela distância entre o cliente e o servidor, e nenhum ajuste permite ficar abaixo desse valor.
• Roteamento de rede. Os pacotes raramente seguem o caminho mais curto. Eles passam por provedores de trânsito, pontos de troca de tráfego e pontos de peering, cada um adicionando microssegundos a milissegundos. Um peering ineficiente pode dobrar ou triplicar o mínimo teórico.
• Processamento do lado do servidor. Assim que o pedido chega, o servidor ainda tem de o processar: análise, consultas à base de dados, E/S de disco, lógica da aplicação. Uma única consulta lenta pode adicionar segundos, ofuscando completamente a parte da rede.

Faixas aproximadas de tempo de ida e volta que vale a pena conhecer:

• LAN: menos de 1 ms
• Mesma região: 10-30 ms
• Entre estados (leste-oeste dos EUA): 60-80 ms
• Transatlântico: 70-100 ms
• Transpacífico: 130-180 ms
• Satélite geoestacionário: 500 ms+ (serviços LEO como o Starlink: 20-50 ms)

8 formas de reduzir a latência do servidor

1. Aproxime o processamento com a computação de ponta

A computação de ponta executa a lógica das aplicações em servidores fisicamente próximos dos utilizadores, em vez de num único centro de dados central. Para cargas de trabalho em que cada pedido desencadeia uma viagem de ida e volta (APIs interativas, jogos em tempo real, inferência de IA), isto reduz a parte da latência da rede para milésimos de segundo de um único dígito. Ideal para utilizadores distribuídos globalmente com cargas de trabalho sensíveis à latência.

2. Armazene conteúdo em cache numa CDN

Uma CDN armazena conteúdo estático e, cada vez mais, dinâmico em nós de borda em todo o mundo, para que os utilizadores obtenham a cópia mais próxima, em vez de a sua origem. A vantagem mais fácil e significativa para qualquer site que atenda tráfego global, especialmente para mídia, JavaScript, CSS e respostas de API que podem ser armazenadas em cache. As CDNs modernas suportam purga em tempo real e regras de cache baseadas em cabeçalhos de solicitação.

3. Isolar o tráfego com VLANs privadas

As VLANs privadas dividem o tráfego de rede em sub-redes isoladas, para que cargas de trabalho não relacionadas não partilhem domínios de difusão. Em conjunto com políticas de QoS, garantem largura de banda a serviços sensíveis à latência (VoIP, replicação de bases de dados, videochamadas), independentemente do que mais estiver a ser executado na mesma infraestrutura física. É mais uma solução multi-tenant ou de LAN de grande dimensão do que uma solução de servidor único.

4. Priorizar o tráfego crítico com QoS

As regras de Qualidade de Serviço indicam ao equipamento de rede quais os pacotes que têm prioridade durante o congestionamento. As consultas à base de dados e as chamadas API têm prioridade; as cópias de segurança e a replicação em massa ficam com o que sobrar. Verdadeiramente eficaz em ligações que ficam periodicamente saturadas. Inútil em ligações que nunca ficam.

5. Atualize para hardware mais rápido

As maiores vantagens do lado do servidor provêm de alguns componentes:

• Armazenamento NVMe a substituir SSDs SATA, para uma latência de E/S 10 a 100 vezes menor
• NICs modernas com suporte a RSS, RDMA ou DPDK para altas taxas de pacotes
• RAM suficiente para manter os dados ativos na memória e evitar leituras do disco
• CPUs com núcleos suficientes e desempenho por núcleo para evitar conflitos de troca de contexto

Um servidor único com especificações corretas tem frequentemente um desempenho superior ao de um cluster com especificações inadequadas.

6. Distribuir a carga pelos servidores

O balanceamento de carga distribui as solicitações por vários backends para que nenhum servidor se torne um gargalo. Algoritmos padrão (round-robin, menos conexões, ponderado) funcionam para serviços sem estado; sessões persistentes são importantes para serviços com estado. O balanceamento de carga geográfico via anycast ou GeoDNS direciona os utilizadores para o servidor ativo mais próximo, reduzindo o RTT para públicos globais.

7. Otimizar aplicações e bases de dados

Muitas vezes, a maior vantagem. Os suspeitos habituais:

• Índices de base de dados em falta ou não utilizados
• Padrões de consulta N+1 devido ao uso indevido de ORM
• E/S sequencial onde a paralela funcionaria
• Ausência de cache na memória (Redis, Memcached) para leituras repetidas
• Operações de bloqueio em caminhos de código ativos

Analise o perfil antes de otimizar. Ferramentas como py-spy, perf ou um APM adequado mostram onde o tempo é realmente gasto, em vez de onde se presume que seja gasto.

8. Monitorize continuamente

Não se pode corrigir o que não se vê. Acompanhe o RTT, a perda de pacotes, o jitter e os tempos de resposta percentuais (p50, p95, p99). O p99 é normalmente onde se esconde uma má experiência do utilizador. Ferramentas que vale a pena conhecer: mtr para diagnóstico de percursos, o Smokeping para tendências, o Prometheus e o Grafana para séries temporais e um APM (Datadog, New Relic, Sentry) para visibilidade ao nível da aplicação.

Comparando as 8 abordagens

Como escolher o que se adequa

Escolha com base no recurso de que dispõe em menor quantidade:

• Orçamento limitado. Comece com a otimização de aplicações e bases de dados, acrescente monitorização e, em seguida, gestão de largura de banda. Estas opções implicam tempo de engenharia, não de infraestrutura.
• Tempo de engenharia limitado. Uma CDN e uma atualização de hardware proporcionam grandes ganhos com um baixo esforço de configuração.
• Utilizadores distribuídos globalmente. CDN em primeiro lugar. Adicione computação de ponta para as partes que não podem ser armazenadas em cache.
• Cargas de trabalho em que a latência é crítica (jogos em tempo real, negociação, inferência de IA). Atualizações de hardware e implementação na periferia em conjunto. Só com truques de aplicações não vai conseguir o que pretende.
• Tráfego já elevado. O balanceamento de carga e a monitorização devem estar implementados antes de escalar qualquer outra coisa.

Considerações finais

Os maiores ganhos provêm de duas fontes: reduzir a distância física com uma CDN ou nós de borda e corrigir as ineficiências do lado do servidor que transformam 50 ms de latência de rede em 500 ms de tempo de resposta total. A maioria das equipas subestima o segundo aspeto.

Para cargas de trabalho sensíveis à latência, a rede subjacente é tão importante quanto o código que a utiliza. Os servidores dedicados da FDC são fornecidos numa rede com boas ligações em mais de 70 locais globais, com largura de banda ilimitada e hardware moderno (EPYC, NVMe). Isso dá-lhe uma base que não cria estrangulamentos nas coisas que não pode resolver no código.