Como ajustamos nosso RPC para velocidade e confiabilidade

Somos obcecados por performance e estamos constantemente ajustando para otimizar ainda mais nossa plataforma. Recentemente mudamos a forma como nossa plataforma comprime respostas RPC grandes, e uma parte dessa mudança teve um efeito desproporcional para a Worldchain. Respostas comprimidas em chamadas grandes agora retornam cerca de 33% mais rápido, o que significa leituras de blocos completos e outras chamadas pesadas mais rápidas, performance mais estável e mais margem para acomodar o crescimento de tráfego.

O que é um frame GOAWAY?

Se você executa uma carga de trabalho de alto throughput sobre HTTP/2, você conhece frames GOAWAY mesmo que nunca tenha pesquisado sobre eles. Um GOAWAY é o sinal que um servidor envia para dizer a um cliente para parar de abrir novos streams em uma conexão, geralmente porque o servidor está descartando carga. Para o cliente, uma rajada de GOAWAYs aparece como instabilidade de conexão: streams são cortados, requisições são reenviadas em conexões novas, e a latência de cauda aumenta.

Menos GOAWAYs significa conexões mais estáveis, menos retentativas e serviço mais rápido. Então, quando a contagem de GOAWAYs de um cliente despenca, alguma coisa acima na cadeia ganhou bem mais margem. Nesse caso, essa coisa era CPU.

Onde a compressão rodava antes

Toda resposta RPC que retornamos pode ser comprimida antes de sair da nossa rede. A maioria dos clientes HTTP solicita isso enviando um cabeçalho Accept-Encoding: gzip, e a maioria dos servidores web, incluindo nosso próprio node-gateway, respeita esse cabeçalho automaticamente. Isso não é um recurso especial que construímos. É comportamento padrão. Para payloads grandes, como leituras de blocos completos ou grandes conjuntos de resultados de eth_getLogs, a compressão reduz significativamente o número de bytes enviados pela rede, o que importa porque a largura de banda da internet é limitada.

Comprimir no node-gateway fazia sentido durante muito tempo. O node-gateway é um serviço limitado por IO: ele passa a maior parte do tempo esperando por chamadas de rede, seja de clientes ou de nossos próprios nodes, então historicamente tinha CPU sobrando. Compressão é trabalho limitado por CPU, e seu custo cresce com o tamanho da resposta. Em escala, isso se tornou um dos trabalhos mais movimentados e sensíveis à latência que o gateway fazia, competindo pela mesma CPU que ele precisa para rotear e servir cada requisição.

Quando o gateway roda sob alta carga, tudo que ele faz desacelera ao mesmo tempo. E pressão de CPU no gateway sob carga é exatamente a condição que dispara o descarte de conexões e frames GOAWAY.

O que mudamos?

Movemos o local onde a compressão de dados acontece do nosso node-gateway para um proxy Istio em nosso service mesh. O node-gateway não comprime mais as respostas. Esse trabalho agora acontece em uma etapa diferente, em um proxy Istio, em infraestrutura mais adequada para isso. Assim, o node-gateway da Alchemy fica livre para otimizar velocidade e confiabilidade, e o Istio cuida da etapa de compressão.

O resultado é a mesma resposta comprimida para nossos clientes, produzida em algum lugar que consegue fazer isso de forma mais eficiente, sem competir por ciclos no salto que limita a performance. Mesma stack, mesma saída, apenas feita em um lugar melhor.

O que isso significa para você?

Respostas comprimidas em chamadas grandes agora retornam cerca de 33% mais rápido (a latência P95 melhorou cerca de 35%). Isso se desdobra em três coisas.

Conexões mais estáveis. Quando o salto que serve suas requisições não está disputando CPU, ele para de descartar carga, então você tem menos GOAWAYs, menos streams cortados e menos retentativas forçadas. Foi isso que a Worldchain viu: erros de conexão caindo de aproximadamente 1.500 por hora para aproximadamente 100.

Respostas mais rápidas nas suas chamadas pesadas. Lidar com a compressão no proxy Istio permite que o primeiro byte de uma resposta grande saia mais cedo. Para payloads grandes como leituras de blocos completos ou grandes conjuntos de resultados de eth_getLogs, isso significa menos tempo até a chegada do primeiro trecho da resposta.

Mais margem por baixo do seu tráfego. Liberamos capacidade significativa de CPU exatamente no salto que limita sua performance. A correção se mantém por requisição, então continua se sustentando conforme seu tráfego cresce. Você não precisa mudar nada para se beneficiar. Ela já está rodando sob cada requisição que você envia.

Por que isso importa

A maior parte do que torna um provedor de RPC rápido e confiável acontece onde você nunca vê, em saltos como esse. Um único serviço fazendo menos do trabalho errado, no lugar certo, se transformou em conexões mais estáveis e respostas mais rápidas da noite para o dia, sem nada para os clientes mudarem do lado deles.

Essa é uma mudança em um esforço contínuo para melhorar nosso caminho de serviço. Comece a construir na Alchemy.