Pular para o conteúdo

Compare o desempenho de RPC entre chains populares

Veja como os provedores se comparam em latência, taxa de sucesso e requisições com falha, todos testados sob as mesmas condições.

Tempo médio de resposta global (EVM)

Ao vivo

Última atualização: Sep 25, 2026, 10:33 UTC

Alchemy0.00 ms
QuickNode0.00 ms
dRPC0.00 ms
Infura0.00 ms

No benchmark global das últimas 24 horas entre chains EVM, Alchemy tem o menor tempo médio de resposta, com 13.98 ms.

Chains
Regiões

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0%

Alchemy

Comparação de provedores para todas as chains avaliadas em todas as regiões

Nesta visualização de 24 horas, Alchemy tem a menor latência média, com 13.98 ms. A tabela também mostra P50, P95 e taxa de sucesso para cada provedor.

Tabela de benchmark de provedores RPC comparando latência média, latência P50, latência P95 e taxa de sucesso para a chain e região selecionadas.
ProvedorLatência médiaLatência P50Latência P95Taxa de sucesso
AlchemyMais rápido
13.98 ms
6.77 ms
30.28 ms
100%
QuickNode
47.29 ms
9.79 ms
207.67 ms
99.99%
dRPC
101.51 ms
21.11 ms
574.54 ms
99.99%
Infura
121.83 ms
104.22 ms
281.75 ms
99.99%

Latência média por método: todas as chains avaliadas, todas as regiões

Escolha um método para ver com que rapidez cada provedor lida com esse tipo de requisição.

7.54 ms
13.46 ms
20.13 ms
113.86 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

Requisições com falha por método: todas as chains avaliadas, todas as regiões

Escolha um método para ver onde os erros e timeouts se concentram por provedor.

0
0
0
4
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

Metodologia

Testes de RPC controlados, regras transparentes

Estes são benchmarks de leitura EVM no nível de método. Enviamos os mesmos payloads configurados a partir das mesmas regiões, separamos velocidade de confiabilidade e publicamos as regras para que os números sejam mais fáceis de interpretar.

Leia a metodologia completa
Payload icon

Mesmos payloads

Para cada método, todo provedor recebe o mesmo payload JSON-RPC configurado, a mesma chain, região, timeout e critérios de sucesso.

Regions icon

Regiões de execução compartilhadas

Os testes rodam a partir de US East, US West, EU Central e AP Southeast, com cada provedor testado a partir do mesmo local de execução.

Accounts icon

Contas pagas padrão

Todo provedor é testado em uma conta paga padrão de serviço RPC, sem rotas especiais, planos, retries ou tratamento diferenciado.

Latency icon

Latência de respostas bem-sucedidas

A latência usa conexões HTTP aquecidas e reutilizadas, e considera apenas respostas bem-sucedidas. As falhas são rastreadas separadamente.

Failure rules icon

Regras de falha claras

Erros HTTP, erros JSON-RPC, falhas de parse, erros de rede, limites de taxa e timeouts de 8 segundos contam todos como falhas.

Scope icon

Escopo no nível de método

O benchmark mede requisições de leitura individuais, não fluxos completos de aplicativos, escritas, WebSockets, cold starts ou combinações personalizadas de tráfego.

Benchmarks para agentes

Abra cada visualização de benchmark como tabelas de texto com definições de campos e metadados de origem, feitas para agentes, crawlers e desenvolvedores que querem os dados sem a interface.

Abrir dados em Markdown

Perguntas frequentes

Perguntas frequentes sobre o benchmark

Como funcionam os benchmarks de RPC ao vivo, o que eles medem e onde encontrar os dados brutos.

  • Eles acompanham a latência de respostas bem-sucedidas (média, P50 e P95), a taxa de sucesso e a contagem de requisições com falha para Alchemy, QuickNode, dRPC e Infura em métodos de leitura JSON-RPC comuns do EVM.
  • As requisições do benchmark rodam a cada 10 segundos, ininterruptamente. A página pública e a rota de dados em Markdown são atualizadas a cada 5 minutos com a janela mais recente de 24 horas.
  • O benchmark roda a partir de US East, US West, EU Central e AP Southeast. A visualização Global agrega os resultados dessas quatro regiões.
  • Eles comparam contas pagas padrão de serviço RPC. Todo provedor recebe o mesmo método configurado, payload, chain, região, timeout e critérios de sucesso, sem tratamento especial.
  • Uma requisição falha se retornar um status HTTP que não seja 2xx, retornar um objeto de erro JSON-RPC, atingir o timeout após 8 segundos, falhar no nível de rede ou não conseguir ser interpretada como JSON válido. Respostas de limite de taxa contam como falhas.
  • A latência é o tempo de requisição e resposta medido pelo executor para um POST HTTP JSON-RPC bem-sucedido, em uma conexão aquecida e reutilizada. Tentativas com falha e timeouts são excluídos da latência e contados na taxa de sucesso.
  • Não. Cada requisição tentada tem uma única chance. Se falhar, a falha é contabilizada em vez de ser eliminada por uma nova tentativa, para que a taxa de sucesso reflita as falhas que um aplicativo precisaria tratar.
  • Os benchmarks ao vivo cobrem Ethereum, Optimism, Arbitrum, Base e World Chain, além de uma visualização Overall que agrega as chains atualmente avaliadas.

  • O benchmark cobre testes de leitura EVM configurados para:

    • eth_getBalance: consulta de saldo de conta
    • eth_getBlockByNumber: bloco mais antigo, leitura de cabeçalho no início da chain
    • eth_getBlockByNumber: bloco mais recente, leitura de cabeçalho na ponta da chain
    • eth_getLogs: intervalo de 1 bloco
    • eth_getLogs: intervalo de 10 blocos
    • eth_getLogs: intervalo de 100 blocos
    • eth_getLogs: intervalo de 1.000 blocos na Ethereum
    • eth_getTransactionReceipt: consulta de recibo de uma única transação
  • Sim. A página complementar em Markdown publica os resultados como tabelas de texto com definições de campos, metadados de origem e o conjunto completo de dados por chain e região.
  • O P95 mostra a extremidade lenta das respostas bem-sucedidas: 95% das requisições bem-sucedidas naquele método, chain, região e janela de tempo foram concluídas nessa latência ou abaixo dela. Leia essa métrica junto com a taxa de sucesso, pois respostas rápidas só importam quando as respostas realmente chegam.
  • Eles medem o desempenho de leitura EVM de método único, com conexões aquecidas, sob condições controladas. Não medem fluxos completos de aplicativos, transações de escrita, WebSockets, combinações de tráfego específicas de clientes, configuração de conexão a frio, nem todas as combinações possíveis de chain, provedor, região, método e payload.

Latência é um imposto sobre seus usuários

Toda chamada RPC lenta se transforma em atrito visível para o usuário: leituras atrasadas, telas travadas e confirmações que parecem quebradas. Construa sobre uma infraestrutura que mantém seu aplicativo em movimento.

Comece a construirFale conosco