Skip to main content
AVISO CRÍTICO: Somente Data Center de ProduçãoEsses testes de latência são projetados para ambientes de data center de produção apenas. NÃO execute esses testes em máquinas locais ou conexões de internet domésticas. A largura de banda local não pode lidar com assinaturas pesadas de Solana e produzirá resultados sem sentido que não refletem o desempenho do mundo real.
REQUISITO DE COLOCAÇÃO: Implante Próximo ao Seu Endpoint LaserStreamPara medições de latência significativas, você deve colocar sua infraestrutura de teste na mesma região do seu endpoint LaserStream escolhido. A distância de rede dominará suas medições - testar de um continente diferente mostrará a latência da rede, não o desempenho do LaserStream.

Entendendo a latência em sistemas de blockchain distribuídos

Ao trabalhar com serviços de streaming de blockchain, a medição de latência torna-se complexa porque os sistemas distribuídos não têm um relógio universal. Ao contrário dos sistemas tradicionais onde você pode medir o tempo de ida e volta para um único servidor, as redes blockchain envolvem vários validadores, cada um recebendo e processando a mesma transação em momentos diferentes. O desafio fundamental: Blockchains como Solana não têm um conceito de tempo absoluto. Cada nó validador globalmente receberá a mesma transação em momentos diferentes, e a confirmação depende de uma porcentagem do cluster atingir o consenso. Isso torna a medição determinística de latência impossível no sentido tradicional.

Níveis de compromisso e prioridades de latência

Solana oferece três níveis de compromisso, cada um com características de latência diferentes:
  • Processado: Mais rápido, confirmação de um único validador (~400ms)
  • Confirmado: Médio, confirmação de supermaioria (~2-3 segundos)
  • Finalizado: Mais lento, finalização completa da rede (~15-30 segundos)
Para aplicações sensíveis à latência, compromisso processado é tipicamente o alvo. Todos os testes neste guia utilizam o nível de compromisso processado, já que a maioria dos casos de uso de alta frequência prioriza a velocidade sobre a finalidade absoluta.

Três abordagens para medir a latência

1. Comparando fluxos gRPC paralelos

Método mais confiável - Compara dois fluxos independentes para a mesma fonte de dados, medindo qual recebe eventos idênticos primeiro. Vantagens:
  • Elimina problemas de sincronização de relógio
  • Fornece comparação de desempenho relativo
  • Mais preciso para comparar serviços

2. Comparação de timestamp local vs created_at

Confiabilidade moderada - Mede a diferença entre quando seu sistema recebe uma mensagem e o timestamp incorporado na mensagem pelo serviço LaserStream. Limitações:
  • Apenas representa quando o LaserStream criou a mensagem internamente
  • Atrasos a montante para o LaserStream não serão capturados
  • Menos preciso do que o Método 1 para latência verdadeira de ponta a ponta

3. Análise de timestamp de bloco (não recomendado)

Não recomendado - Compara o tempo de recebimento local com o timestamp de bloco da Solana. Limitações significativas:
  • Timestamps de bloco têm apenas granularidade de segundo
  • Solana produz blocos a cada 400ms
  • Fornece informações mínimas úteis

Requisitos de configuração

Co-locação regional

Para medições de latência significativas, implante sua infraestrutura de teste no mesmo data center ou região que seu endpoint LaserStream. Regiões LaserStream disponíveis:
  • ewr: Nova York, US (Costa Leste)
  • pitt: Pittsburgh, US (Central)
  • slc: Salt Lake City, US (Costa Oeste)
  • ams: Amsterdã, Europa
  • fra: Frankfurt, Europa
  • tyo: Tóquio, Ásia
  • sgp: Singapura, Ásia
Para testes devnet, use: Veja a documentação do LaserStream gRPC para instruções completas de configuração e diretrizes de seleção de endpoint.

Configuração do ambiente Rust

Todos os scripts de medição usam Rust com Cargo. Configuração básica:
Crie um arquivo com suas credenciais:
Obtenha sua chave de API Helius no Painel Helius. O devnet do LaserStream está disponível em todos os planos. O acesso à mainnet requer um plano Business ou Professional.

Método 1: Comparação de fluxo paralelo

Este script estabelece duas conexões independentes para diferentes endpoints gRPC e mede qual recebe as mesmas mensagens primeiro. Esta abordagem elimina problemas de sincronização de relógio usando tempo relativo.
O que isso mede: A diferença de desempenho relativa entre dois serviços de streaming. O delta mostra qual serviço entrega a mesma informação de slot primeiro. Métricas principais:
  • Delta positivo: Primeiro serviço (YS) mais lento que o segundo serviço (LS) - LaserStream é mais rápido
  • Delta negativo: Primeiro serviço (YS) mais rápido que o segundo serviço (LS) - LaserStream é mais lento
  • Média/Mediana: Diferença média de desempenho
  • P95: Diferença de latência do percentil 95
Executando o teste:
Saída de exemplo:
A saída mostra diferenças de latência em tempo real e estatísticas periódicas. Um delta médio positivo indica que o segundo serviço (LaserStream) consistentemente entrega dados mais rápido.

Método 2: Análise de timestamp criado

Esta abordagem compara o timestamp embutido nas mensagens contra o tempo do seu sistema local ao recebê-las.
Limitação importante: Este método só mede desde quando o LaserStream criou a mensagem até quando você a recebeu. Não leva em conta quaisquer atrasos a montante entre o evento do blockchain e o processamento do LaserStream. Executando o teste:
Saída de exemplo:
Este método fornece insights sobre a latência de rede e processamento entre o LaserStream e seu aplicativo, mas deve ser usado em conjunto com o Método 1 para uma análise abrangente.

Melhores práticas para testes de latência

Princípios-chave

  • Co-locação: Implante os testes na mesma região do seu endpoint LaserStream para minimizar a latência de rede
  • Métodos múltiplos: Use a comparação de fluxo paralelo (Método 1) como sua métrica principal, complementada pela análise de timestamps
  • Monitoramento a longo prazo: Execute testes por períodos prolongados para capturar diferentes condições de rede e congestionamento do blockchain
  • Análise estatística: Foque em percentis (P95, P99) em vez de apenas médias para entender a latência na cauda

Interpretando resultados

  1. Estabelecer linha de base: Execute testes por pelo menos 1 hora para estabelecer desempenho básico em condições normais
  2. Identificar padrões: Procure por padrões em picos de latência - eles se correlacionam com alta atividade do blockchain ou congestionamento da rede?
  3. Comparar percentis: A latência P95 é frequentemente mais importante do que a latência média para a experiência do usuário
  4. Monitorar consistência: Desempenho consistente é frequentemente mais valioso do que a latência mínima absoluta
Lembre-se de que a latência do blockchain é inerentemente variável devido aos requisitos de consenso de rede. Foque em diferenças de desempenho relativas e consistência sobre números absolutos.