FAQ - Latência e regiões
As perguntas sobre cobrança, o plano Free, pagamento e erros 401 ou 429 estão em Como começar.
Perguntas não específicas de uma chain
Estas perguntas tratam de como a distância, a região, a localização dos servidores, endpoints compartilhados ou dedicados e a linguagem do seu cliente afetam a latência.
P. Preciso escolher uma região?
Com o Edge RPC, você não precisa escolher uma região. Uma aplicação que se conecta a edge.erpc.global é direcionada automaticamente para um ponto de entrada próximo no caminho de rede.
Com o Unlimited Endpoints para Solana, Ethereum e Avalanche C-Chain, você escolhe a região ao fazer o pedido, perto de onde seu sistema de trading ou backend é executado. Confira as regiões disponíveis no ERPC Web Dashboard ao fazer o pedido.
Na Solana, nenhuma região serve para todas as estratégias, porque o papel de líder passa de um validador para outro conforme a agenda de líderes; veja a seção Solana mais abaixo.
P. Estou com latência alta. Por quê?
Você está acessando o endpoint de um local fisicamente próximo? A distância afeta significativamente a latência. Recomendamos acessar a partir de servidores próximos ao endpoint fornecido.
Teoricamente, nossa rede oferece as conexões mais rápidas por meio dos nossos servidores Bare-Metal e serviços VPS.
P. Como é a latência?
A latência varia dependendo do método de medição e do seu ambiente de uso específico. Em vez de se concentrar em valores numéricos exatos, é crucial garantir que a latência atenda aos seus requisitos operacionais reais.
Para a Solana, você pode medir a latência com estas ferramentas open source para TypeScript e Rust.
P. Por que os endpoints dedicados são mais rápidos?
Endpoints compartilhados são usados por vários clientes que compartilham os mesmos recursos. À medida que o tráfego aumenta, tende a surgir latência. Os recursos do servidor têm limites físicos, e a quantidade de trabalho com que eles conseguem lidar é finita. Quando chegam requisições demais ao mesmo tempo, elas precisam ser processadas sequencialmente, o que resulta em tempos de resposta mais lentos.
Embora tomemos várias medidas para otimizar o desempenho mesmo em endpoints compartilhados, com endpoints dedicados você é o único usuário do recurso. Isso significa que você não é afetado de forma alguma por outros usuários, garantindo respostas consistentemente estáveis e rápidas.
Além disso, endpoints dedicados fornecem opções de comunicação sem TLS, como HTTP. Ao evitar o handshake TLS (cerca de 20ms), a comunicação torna-se ainda mais rápida em comparação com HTTPS.
P. Qual plano oferece o desempenho mais rápido?
Geralmente, nosso plano de nível mais alto oferece o desempenho mais rápido devido a CPUs superiores, capacidades de memória mais elevadas e configurações de hardware robustas.
Nós também oferecemos soluções personalizadas se você precisar de servidores ainda mais poderosos, mas nossos planos padrão são projetados para oferecer uma relação preço-desempenho ideal.
Estamos confiantes em fornecer desempenho de nível mundial em todas as faixas de preço. Se você encontrar um provedor mais rápido dentro da mesma faixa de preços, por favor, avise-nos para que possamos investigar e fazer melhorias.
P. A latência não é o que eu esperava.
O desempenho pode variar significativamente dependendo da linguagem de programação utilizada. Normalmente, as comparações de velocidade entre linguagens apresentam a seguinte classificação:
Rust > Go > TypeScript (JavaScript) > Python
Para comparações mais detalhadas, consulte o seguinte recurso:
Recomendamos fortemente o uso de Rust se o seu objetivo for o desempenho máximo.
Solana
Estas respostas dependem de como a Solana funciona: o papel de líder passa de um validador para outro conforme a agenda de líderes, por isso a localização dos validadores influencia a região que você escolhe.
P. Qual região você recomenda?
Não existe uma única região que seja sempre a melhor. A Solana é global, e o papel de líder passa de um validador para outro conforme a agenda de líderes. Regiões com mais validadores e mais stake recebem leader slots com mais frequência, o que pode ajudar as transações a serem incluídas em bloco mais rapidamente. O trade-off é que o tráfego concorrente também se concentra lá, por isso uma região menos congestionada pode às vezes oferecer melhores resultados, dependendo da sua estratégia.
Como ponto de partida prático, escolha uma região com alta densidade de validadores, como Frankfurt ou a Costa Leste dos EUA, quando o mais importante for uma oferta estável de leader slots, ou posicione sua infraestrutura perto de um validador-alvo específico quando a prioridade for a execução pelo caminho mais curto. Use o Validators Solutions para entender a distribuição pública da rede Solana e, em seguida, use a ERPC Leader Slot API e medições reais para decidir se é mais adequada uma implantação em uma única região, em duas regiões ou global.
P. Preciso de uma latência de ~400ms ou menos.
Para alcançar uma latência de aproximadamente 400ms ou menos, considere estes pontos essenciais:
-
Compreensão realista dos valores de ping: Os valores de ping indicam condições ideais e não refletem a latência real das comunicações de streaming, que normalmente fica em torno de 5 vezes a latência do ping. Por exemplo, um ping de 100ms entre continentes resulta, na prática, em cerca de 500ms de latência. Por isso, a infraestrutura precisa estar na mesma região para atingir uma latência de ~400ms.
- Valores de ping típicos (referência):
- Mesma rede: ~0.1ms
- Interconexão de rede privada (PNI): ~0.2ms
- Mesmo data center: ~0.3ms
- Mesma cidade: ~1ms
- País vizinho: ~5–10ms
- Intercontinental: ~100–300ms
- Valores de ping típicos (referência):
-
A armadilha da latência média: Os validadores da Solana estão espalhados geograficamente pelo mundo, e a agenda de líderes muda aleatoriamente a cada época. Contar com a latência média para atingir ~400ms não é prático. Em vez disso, você deve acompanhar com precisão as agendas dos validadores na sua região específica para identificar os slots com a menor latência. Para obter a latência mínima de forma consistente, é necessária infraestrutura em todas as regiões relevantes. Dentro da mesma região, a aquisição de dados pode levar dezenas de milissegundos, e a transmissão, apenas alguns milissegundos.
-
Acompanhamento da agenda de líderes: Monitore a agenda dos validadores líderes da sua região usando a ERPC Leader Slot API (
getLeaderSlots). Ela retorna a agenda dos próximos líderes, o stake weight da época atual, a geolocalização estimada dos validadores e valores de ping de referência, para que você possa identificar os slots de menor latência a ter como alvo antes que eles cheguem. Dados públicos em formato de mapa e APIs RPC nativas são úteis para uma visão ampla da rede, mas não são precisos o suficiente para o timing de execução. A Leader Slot API preenche essa lacuna com a granularidade necessária para decisões de roteamento e negociação.
Dados da rede Solana: Validators Solutions
P. Como posso alcançar a negociação de bloco zero (zero-slot)?
Ter sucesso na negociação de bloco zero (zero-slot) exige estratégias mais sofisticadas, como as seguintes:
-
Identificação de zonas de oportunidade: Os validadores da Solana estão distribuídos pelo mundo, e é fisicamente impossível alcançar a latência ideal em todos os slots. Portanto, monitore a agenda de líderes dos validadores na região onde sua infraestrutura está localizada e identifique as zonas de oportunidade mais favoráveis. A implantação de infraestrutura em várias regiões também pode ser vantajosa. Por exemplo, Frankfurt é uma região-chave devido à sua alta densidade de validadores, o que resulta em uma seleção de líderes mais frequente e em mais oportunidades de negociação.Use a ERPC Leader Slot API (
getLeaderSlots) para consultar a agenda dos próximos líderes, o stake weight da época atual, dados estimados de geolocalização dos validadores e valores de ping de referência com uma precisão muito maior do que a das fontes públicas de dados em formato de mapa ou das APIs RPC nativas. Isso permite mapear as zonas de oportunidade antes que os slots cheguem e executar operações com latência quase zero. -
Implantação de nós dedicados: Se estiver tendo dificuldade para competir, considere implantar nós dedicados. Nós compartilhados sofrem latência devido ao tráfego de outros usuários e, por isso, não são recomendados. Além disso, colocar seu nó dedicado na mesma rede que sua aplicação reduz significativamente a latência de rede e otimiza o desempenho.
P. Qual é o mais rápido: WebSockets, gRPC ou Shreds?
O feedback de muitos clientes é bastante consistente, e a ordem de desempenho é a seguinte:
Shreds > gRPC > WebSockets
Se descobrir resultados ou condições diferentes, informe-nos.
P. Este RPC (gRPC, Shreds) é mais rápido do que outros?
Projetamos todos os níveis de plano pensando em velocidade e teremos prazer em ver essa velocidade medida lado a lado com qualquer outro provedor. Os resultados podem variar conforme a região, o uso de um endpoint compartilhado ou dedicado, o protocolo (WebSockets, gRPC ou Shreds) e a linguagem de programação do seu cliente.
Se o nosso serviço parecer mais lento, informe-nos pelo ERPC Web Dashboard as condições específicas e os concorrentes com os quais você o comparou. Vamos identificar a causa e melhorar ainda mais a velocidade.