Como fazer benchmark de provedores de RPC para o seu workflow

A escolha de um provedor de RPC deve se basear em benchmarks específicos da sua carga de trabalho. Fazemos benchmark de provedores o tempo todo, inclusive de nós mesmos, e já vimos muitas equipes fazerem o mesmo. Enviar as requisições é a parte fácil. A parte difícil é decidir o que medir e depois construir um teste cujo resultado você realmente usaria para tomar uma decisão.

Por isso documentamos a metodologia e construímos o Alchemy rpcbench para executá-la: um único binário que faz benchmark de qualquer conjunto de provedores de RPC a partir da sua própria máquina, nos métodos que o seu app realmente chama. A metodologia em si funciona com qualquer ferramenta que você já tenha.

Vale medir três coisas: latência sob carga, atraso de bloco e consistência de dados. Cada uma quebra uma parte diferente do seu sistema, e um provedor forte em uma pode ficar atrás em outra, então uma pontuação combinada esconde justamente a que importa para você. Meça o que o seu app realmente chama, a partir de onde ele roda.

O que você deve medir ao fazer benchmark de um provedor de RPC?

Latência sob carga, atraso de bloco e consistência de dados, medidos e reportados separadamente.

A consistência de dados é a que a maioria das equipes nunca testa. Alguns provedores servem métodos diferentes a partir de backends diferentes, e eles nem sempre avançam juntos, então um provedor pode anunciar um novo head enquanto os logs desse mesmo bloco voltam incompletos. Pense numa biblioteca que atualiza o catálogo antes de os livros chegarem às prateleiras: o catálogo diz que a novidade chegou, e a prateleira está vazia.

Qual delas você deve medir primeiro?

Comece pela que corresponde ao que o seu app faz com os dados. Se você age sobre novos blocos, é o atraso de bloco. Se você lê os logs ou o estado de um bloco no momento em que ele chega, é a consistência de dados. Caso contrário, é a latência sob carga. Já vimos equipes como Valantis, Aave, RedStone e Struct rodarem benchmarks que medem coisas diferentes.

Depois compare os provedores um método por vez, porque um provedor mais rápido na média ainda pode ser mais lento na chamada que o seu app mais faz. Essa diferença é o que decide tudo: uma cotação que chega depois que o spread fechou não é uma cotação lenta. É uma execução perdida.

Como rodar um benchmark de RPC em que você pode confiar?

Envie requisições em um cronograma fixo para medir a latência. O design óbvio é enviar uma requisição, esperar a resposta e então enviar a próxima, e isso discretamente envia menos requisições exatamente quando um provedor começa a ter dificuldades. O seu teste alivia a carga no momento em que deveria mantê-la, então a lentidão que você procurava nunca aparece nos dados. Em vez disso, envie em um relógio fixo e acompanhe quanto cada envio atrasa em relação a ele. Quando a sua própria máquina fica para trás, os números descrevem a sua máquina.

Configurando a execução

Executando

O atraso de bloco é a exceção. "Quem anunciou este bloco primeiro" só faz sentido se todos os provedores forem observados no mesmo momento, e é uma mensagem pequena por bloco, então ninguém disputa a sua largura de banda.

Lendo os resultados

O que é o Alchemy rpcbench?

O Alchemy rpcbench é um único binário que executa toda a metodologia acima a partir da sua máquina, com as suas próprias chaves. Ele envia requisições apenas para os endpoints da sua configuração, e o relatório HTML que ele produz é enviado diretamente para você.

Nós o construímos porque documentar a metodologia é a metade fácil. Cada regra acima leva dias para ser implementada corretamente, e a maioria é invisível quando você erra, que é a pior combinação numa ferramenta de medição.

Os padrões são um ponto de partida. Uma seção workload: substitui os parâmetros e métodos pelos seus:

Os passos de taxa, a duração, o timeout e a janela de atraso de bloco também são configuráveis, e uma etapa de preflight estima o custo da execução em requisições, tempo e largura de banda antes que qualquer carga saia da sua máquina. Essa estimativa é em compute units da Alchemy, então leia-a como uma verificação de tamanho.

Cada execução gera um arquivo JSON, agregados em CSV e um dashboard HTML autocontido. Ele não entrega números que não consegue sustentar. Amostras insuficientes, um provedor com throttling ou uma máquina que ficou para trás são sinalizados no topo.

Uma execução que passa pela validação entrega quatro coisas, nesta ordem:

O que esta metodologia não diz

• Uma região não diz nada sobre outra. Se o seu sistema roda em outro lugar, rode o benchmark a partir de lá.
• O atraso de bloco é relativo ao provedor mais rápido que você testou, não à verdadeira ponta da chain.
• Os métodos rodam um de cada vez, então uma execução nunca reproduz a combinação do seu tráfego real.
• Uma execução é um ponto de dados. Recomendamos fortemente várias execuções para obter um sinal confiável de desempenho, porque muitos fatores podem afetar uma medição, incluindo problemas que afetam a chain inteira.
• A ferramenta Alchemy rpcbench é apenas para redes EVM e suporta uma rede por execução.

Como obter acesso ao Alchemy rpcbench?

O Alchemy rpcbench está em alpha privado. Preencha este formulário para solicitar acesso!

E se você preferir construir por conta própria com as ferramentas que já tem, a metodologia acima é tudo o que precisa. Ficamos felizes de qualquer forma, desde que o número com base no qual você vai agir seja um que você mesmo produziu.

Perguntas frequentes

Como devo comparar provedores de RPC?

Rode a mesma carga de trabalho contra todos os provedores a partir da região onde o seu sistema roda, nos métodos que ele realmente chama. Envie em um cronograma fixo, teste os provedores um de cada vez e fixe um bloco para que todos respondam à mesma pergunta. Leia os resultados método por método, com as contagens de falhas e de rate limit ao lado de cada número de latência, e depois repita em outro horário. Se preferir não construir isso por conta própria, fale conosco para obter acesso ao Alchemy rpcbench.

Qual é a diferença entre latência de RPC, atraso de bloco e consistência de dados?

Latência é quanto tempo um provedor leva para responder a uma requisição que você enviou. Atraso de bloco é quanto tempo ele leva para avisar que existe um novo bloco. Consistência de dados é se os logs, recibos e transações desse bloco podem ser servidos no momento em que ele diz que existe. Um provedor pode ser forte nos três, ou forte em um e atrás em outro, e é por isso que eles ficam em colunas separadas.

Posso confiar nos resultados de uma ferramenta de benchmark criada por um provedor?

Sim, e você não precisa acreditar na nossa palavra. Nenhum caminho de código no Alchemy rpcbench se ramifica de acordo com o provedor com o qual está falando, então timeouts ou retries específicos de um provedor não têm onde se esconder. Aponte qualquer agente de código para o seu clone com o prompt de auditoria do README, e ele verifica por você. A ferramenta roda na sua máquina, com as suas chaves, e os resultados nunca saem da sua pasta de saída.

Devo escolher um provedor de RPC com base em uma única pontuação geral de desempenho?

Não. Uma pontuação composta escolhe os pesos por você, e os pesos certos dependem da sua aplicação. Um indexador fazendo backfill do histórico e um bot de arbitragem correndo contra um bloco não precisam de quase nada em comum de um provedor. Leia a dimensão que corresponde ao que você está construindo e depois leia método por método.

De onde devo rodar um benchmark de RPC?

Da região onde a sua aplicação roda. A latência de RPC depende muito do caminho de rede entre o cliente e o provedor, então um benchmark rodado de um laptop, ou de uma região de nuvem onde você não faz deploy, mede um caminho que o seu tráfego de produção nunca percorre.

Quanto tempo leva para rodar um benchmark de RPC?

O tempo de execução depende de como você configura o teste, mas a configuração padrão leva cerca de duas horas. Você consegue configurar e começar a rodar um teste em menos de 10 minutos. A configuração que acompanha o Alchemy rpcbench envia 280.000 requisições por provedor na Ethereum, em sete métodos e três passos de taxa, em cerca de 48 minutos, e a janela de atraso de bloco acrescenta mais uma hora. Os provedores se revezam, então a fase de latência cresce com a quantidade que você testa. Reserve uma tarde, porque confiança exige amostras.

Preciso de um endpoint WebSocket para fazer benchmark de provedores de RPC?

Para latência, não. Para atraso de bloco e consistência de dados, sim, porque ambos dependem de eth_subscribe e da assinatura de newHeads. Você também precisa de pelo menos dois provedores para medir o atraso de bloco, já que ele mede quem anunciou cada bloco primeiro.

Quais provedores de RPC posso testar?

Qualquer provedor com um endpoint JSON-RPC EVM na chain que você está testando. Você fornece as URLs e as chaves, e nada no método ou na ferramenta depende de quem é o provedor.

A Alchemy publica os próprios benchmarks de RPC?

Sim. Nossa página de benchmarks publica comparações contínuas entre provedores que você pode ler hoje. O Alchemy rpcbench serve para produzir os seus, na carga de trabalho da sua aplicação, a partir da região onde ela roda.