---
title: "Como fazer benchmark de provedores de RPC para o seu workflow"
description: "Faça benchmark de provedores de RPC em latência sob carga, atraso de bloco e consistência de dados, medidos separadamente, nos métodos que o seu app chama, a partir de onde ele roda."
---

# Como fazer benchmark de provedores de RPC para o seu workflow

<ImageBlock
  src="https://media.alchemy.com/blog/how-to-benchmark-rpc-providers-hero-v3.jpg"
  alt="Faça benchmark de provedores na sua carga de trabalho"
  width={1024}
  height={480}
  priority
/>

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.

<EmbeddedTable
  table={{
    columns: [
      { key: "dimension", width: 160, title: "Dimensão", dataType: "object" },
      { key: "what", width: 260, title: "O que mede", dataType: "object" },
      { key: "how", width: 360, title: "Como medir", dataType: "object" },
    ],
    data: [
      {
        dimension: { title: "Latência sob carga", tooltip: "", icon: "" },
        what: {
          title:
            "A rapidez com que um provedor responde às requisições conforme o volume aumenta",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "Avance por alguns testes com RPS de produção. Leia p95 e p99 em cada um, com as taxas de falha e de 429 ao lado",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        dimension: { title: "Atraso de bloco", tooltip: "", icon: "" },
        what: {
          title: "A rapidez com que um provedor entrega novos blocos",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "Assine <code>newHeads</code> em todos os provedores ao mesmo tempo. Registre quem anuncia cada bloco primeiro, e com quanta vantagem",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        dimension: { title: "Consistência de dados", tooltip: "", icon: "" },
        what: {
          title:
            "Se os dados de um bloco podem ser servidos no momento em que ele é anunciado",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "A cada novo head, peça o bloco, os logs, os recibos e as transações dele. Verifique se concordam",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

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.

<EmbeddedTable
  table={{
    columns: [
      {
        key: "building",
        width: 240,
        title: "Se você está construindo",
        dataType: "object",
      },
      { key: "first", width: 260, title: "Meça primeiro", dataType: "object" },
      {
        key: "risk",
        width: 280,
        title: "O que está em risco",
        dataType: "object",
      },
    ],
    data: [
      {
        building: {
          title:
            'Uma DEX ou um motor de cotação onchain (ex.: <a href="/case-studies/how-valantis-built-a-reliable-trading-experience-on-hyperliquid">Valantis</a>)',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "Atraso de bloco, depois <strong>p99</strong> nos <code>eth_call</code>s que a sua lógica de precificação faz",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "Você precifica contra um bloco que já mudou, ou a sua cotação chega depois que o spread fechou",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        building: {
          title:
            'Um protocolo de empréstimo com liquidações (ex.: <a href="/case-studies/how-aave-runs-largest-lending-protocol-alchemy">Aave</a>)',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "Atraso de bloco e consistência de dados, depois <strong>p99</strong> nas suas leituras de health factor e de preço",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "A liquidação dispara um bloco atrasada, ou lê uma posição antes de os dados daquele bloco poderem ser servidos",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        building: {
          title:
            'Um oráculo ou serviço orientado a eventos (ex.: <a href="/case-studies/how-redstone-keeps-price-feeds-reliable-across-51-chains">RedStone</a>)',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "Atraso de bloco e consistência de dados, depois <strong>p99</strong> em <code>eth_getLogs</code> e <code>eth_call</code>",
          tooltip: "",
          icon: "",
        },
        risk: {
          title: "Você perde o gatilho porque os logs voltaram incompletos",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        building: {
          title:
            'Um indexador ou backend de carteira (ex.: <a href="/case-studies/how-struct-is-building-the-data-layer-for-onchain-finance">Struct</a>)',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "<strong>p95</strong> na sua taxa de pico, com as taxas de falha e de 429 ao lado",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "Backfills travam, ou saldos ficam desatualizados enquanto as pessoas estão negociando",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

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

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "Regra", dataType: "object" },
      { key: "why", width: 480, title: "Por que importa", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title:
            "Teste os métodos que a sua aplicação realmente chama e use o mesmo payload em todos os provedores",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Um benchmark só compara o que você enviou. Rode cada método sozinho na taxa máxima, ou os mais caros nunca acumulam uma cauda estável",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "Use uma taxa de RPS parecida com a de produção",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Provedores que parecem idênticos a 50 RPS podem se separar a 300. Observe também a largura de banda, porque um intervalo amplo de <code>eth_getLogs</code> satura o seu link e imita uma degradação",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        rule: {
          title: "Defina o que conta como sucesso",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "A latência conta só as requisições bem-sucedidas, então falhar rápido não ganha crédito. Meça o tempo até o último byte. Mantenha os 429s em um grupo separado",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

### Executando

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "Regra", dataType: "object" },
      { key: "why", width: 480, title: "Por que importa", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title: "Aqueça todos os provedores da mesma forma",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Antes de cada método, para cada provedor, envie dez segundos na taxa máxima e descarte o resultado. Baseado em tempo, nunca em contagem de requisições: 10 requisições a 500 RPS são 20ms de aquecimento",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "Mantenha o cronograma, observe a sua própria máquina",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Sinalize a execução se o p99 do desvio de envio passar de 5ms em 1.000 amostras. A partir daí você está medindo a sua máquina",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        rule: {
          title: "Teste os provedores um de cada vez",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Rode-os juntos e eles disputam a sua largura de banda, então quem vence essa disputa parece mais rápido. Dê a cada um a sua vez e alterne a ordem entre as execuções",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

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

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "Regra", dataType: "object" },
      { key: "why", width: 480, title: "Por que importa", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title:
            "Meça a diferença entre os dois provedores em requisições idênticas. Se essa diferença puder plausivelmente ser zero, considere um empate",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "Provedores dentro dos intervalos de confiança um do outro não são separados pelos seus dados. Abaixo de 100 amostras pareadas, não declare resultado algum",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "Rode duas vezes, a partir de onde o seu sistema roda",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "A latência depende do caminho de rede entre você e o provedor. Rodar duas vezes mostra como o desempenho se sustenta em diferentes condições de rede",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

## 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:

<CodeSnippet
  language="yaml"
  code={`workload:
  - method: eth_call
    params:
      - to: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"  # a contract on your quote path
        data: "0x18160ddd"                                 # and your calldata
      - "$anchor"                                          # the pinned block every provider is asked about`}
/>

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:

<EmbeddedTable
  table={{
    columns: [
      {
        key: "get",
        width: 240,
        title: "O que você recebe",
        dataType: "object",
      },
      { key: "tells", width: 540, title: "O que isso diz", dataType: "object" },
    ],
    data: [
      {
        get: { title: "O veredito de validade", tooltip: "", icon: "" },
        tells: {
          title:
            "Se vale a pena citar esta execução. Leia antes de qualquer outra coisa",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        get: { title: "Comparações", tooltip: "", icon: "" },
        tells: {
          title:
            "Apenas as diferenças grandes o bastante para sobreviver ao ruído. Intervalos sobrepostos aparecem como empate",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        get: { title: "Latência por método", tooltip: "", icon: "" },
        tells: {
          title:
            "p50, p90, p95 e p99 em cada passo de taxa, com as taxas de sucesso, falha e 429 ao lado",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        get: { title: "Atraso de bloco e consistência", tooltip: "", icon: "" },
        tells: {
          title:
            "Quem anunciou cada bloco primeiro, quanto atrás os outros chegaram, blocos perdidos e se os dados de cada head podiam ser servidos",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

## 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](/rpcbench-access) 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](/rpcbench-access) 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](/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.