--- title: "Performance do Solana gRPC: uma metodologia pública de benchmark" description: "Como medimos a latência de entrega do Solana gRPC em seis regiões, com resultados p50, p90 e p99, a configuração completa do teste e os comandos exatos para reproduzi-los." --- # Performance do Solana gRPC: uma metodologia pública de benchmark Números de performance da Solana só são tão úteis quanto o método por trás deles. Um valor de latência sem região, janela de tempo e configuração de teste não pode ser verificado, comparado nem reproduzido. Este post documenta como medimos nossos [streams gRPC para Solana](https://www.alchemy.com/solana-grpc), publica os números que essas medições produzem e inclui a configuração completa para reproduzir o teste contra qualquer endpoint, incluindo o nosso. ## Por que publicar a metodologia? Um único valor de latência não diz nada sobre onde o teste rodou, em que ele se inscreveu, em qual nível de commitment ou em qual janela de tempo. Na Solana, esses detalhes decidem o número: os blocos chegam em menos de um segundo, e as margens entre endpoints de streaming são de poucos milissegundos. Já publicamos [as regras de medição por trás dos nossos benchmarks de requisições](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance); este post faz o mesmo para streaming na Solana. Qualquer pessoa pode conferir um benchmark de requisições enviando a mesma requisição. Um stream é mais difícil de examinar. Não é possível repetir um momento de atividade da chain para ver se seu provedor o entregou rápido, por completo e em ordem. Um método publicado permite que desenvolvedores rodem o teste de novo contra sua própria carga de trabalho, em vez de confiar na palavra de uma das partes. ## O que o benchmark mede? A performance de streaming envolve três perguntas separadas: quando os dados chegam, se todos eles chegam e o que acontece quando a conexão cai. Este benchmark responde à primeira, por região. - **Ida e volta de rede (p50).** O tempo mediano de conexão TCP do runner até o endpoint, em 30 conexões. Depende principalmente da geografia, então mostra quanto sua localização custa antes de qualquer dado trafegar. - **Dispersão de entrega (p90, p99).** Quantos milissegundos depois da entrega mais rápida da execução chega uma mensagem lenta ou de pior caso. A cauda é o que seu sistema sente no pior momento. Um monitor de liquidações não se importa se a atualização típica foi rápida quando a que importava chegou atrasada. Reportamos os dois por região, nunca como uma única média global. ## Como medir o tempo de um stream sem confiar em relógios? Medir o tempo de uma requisição é fácil. Uma máquina a envia e recebe a resposta, então um único relógio cobre toda a ida e volta. Um stream elimina essa conveniência. O evento se origina em um validador, passa pela infraestrutura do provedor e chega ao seu processo assinante em outra máquina, em outro datacenter. Agora há dois relógios envolvidos, e relógios em máquinas separadas podem divergir em vários milissegundos mesmo quando ambos rodam NTP. As margens de entrega entre endpoints bem operados podem ser menores que isso, o que significa que cálculos ingênuos com timestamps podem acabar medindo o erro de relógio em vez da performance. Nosso endpoint marca cada mensagem com o horário em que ela foi criada, e o runner subtrai essa marca do horário em que a mensagem chega. Essa subtração compara dois relógios, então o runner verifica o próprio relógio contra um servidor de horário público antes e depois de cada execução. Um pequeno erro fixo ainda pode permanecer. Reportar cada mensagem em relação à entrega mais rápida da execução elimina esse erro, porque um erro fixo de relógio desloca todas as mensagens pelo mesmo valor e se cancela na subtração. A coluna de ida e volta não precisa de correção, já que o runner mede cada conexão TCP com o próprio relógio. Esses números não informam o tempo total do validador até seu processo e não ranqueiam provedores. Ranquear exige outro teste, com dois streams comparados a partir da mesma máquina, que a seção de reprodução cobre. Dois detalhes mantêm a medição honesta. O nível de commitment é fixado em `processed`, o primeiro nível de confirmação, porque misturar níveis de commitment significa medir pontos diferentes da vida de um evento. E os próprios timestamps de bloco da chain ficam totalmente fora do cálculo. A Solana produz blocos em [menos de um segundo](https://www.alchemy.com/blog/zero-downtime-zero-gaps-solana-grpc-streaming), enquanto os timestamps de bloco só têm resolução de segundos, então são grosseiros demais para enxergar margens de milissegundos. ## Como é uma execução de teste? Todos os números deste post vêm de uma execução com o formato abaixo. Quando a configuração muda, republicamos os números com uma nova data em vez de editá-los no lugar. - **Stream testado:** um único stream de transações gRPC compatível com Yellowstone por execução. - **Conta observada:** PumpSwap, o programa AMM da Pump, `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`, escolhido pelo alto volume de transações. - **Nível de commitment:** `processed` em todas as execuções. - **Tamanho da amostra:** 20.000 transações por região. - **Pontos de observação:** runners em máquinas da [Fly](https://fly.io/) em seis regiões de cliente: Leste dos EUA, Oeste dos EUA, Europa Ocidental, Europa Central, Singapura e Tóquio. A ida e volta de cada runner até o endpoint faz parte dos resultados, porque um benchmark rodado em uma cafeteria mede a cafeteria. - **Cliente:** o exemplo `latency` em Rust do geyserbench, com as configurações padrão de cliente sobre TLS, mostrado na seção de reprodução abaixo. - **Janela de tempo:** de 14 a 16 de outubro de 2026. Toda tabela publicada traz as datas da execução que a produziu. ## Quais são os resultados? Comportamento de entrega do nosso stream gRPC para Solana, medido a partir de um cliente em cada região. Cada linha corresponde a 20.000 transações em um único stream com commitment processed, executado de 14 a 16 de outubro de 2026: A coluna p50 é a ida e volta mediana de rede do runner até o endpoint. As colunas p90 e p99 mostram quantos milissegundos depois da entrega mais rápida daquela execução chega uma mensagem lenta ou de pior caso. Leia o p50 como o custo de distância da sua localização, e o p90 e o p99 como a estabilidade da entrega. Nenhum deles é a latência total de ponta a ponta a partir do validador. A forma certa de calibrar suas expectativas é a linha da sua região: desenvolvedores em Frankfurt devem ler a linha Europa Central, não uma média global puxada para a região que testou mais rápido. Quando [lançamos o Solana gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc), publicamos uma versão inicial dessa afirmação (entrega em média 5 a 15ms mais rápida do que alternativas, medida a partir de us-east-1). Esta tabela é a sucessora multirregional daquele retrato de região única e comparação direta, com uma métrica diferente e complementar. ## Como reproduzir este teste? Você precisa de Rust e de uma chave de API da Alchemy com acesso ao Solana gRPC (o [guia rápido](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart) lista os pré-requisitos). Três comandos: Ele abre um stream gRPC para Solana, observa 20.000 transações em uma conta movimentada com commitment processed e imprime a ida e volta mediana de rede até o endpoint e, em seguida, quantos milissegundos acima da entrega mais rápida chegam suas mensagens p50, p90 e p99. Rode em um servidor na região que importa para você e compare com a tabela acima. Usamos `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`, PumpSwap, o programa AMM da Pump. É uma boa escolha porque tem volume muito alto, então 20.000 transações chegam rápido. Para observar outro programa ou rodar um teste mais curto, defina `ACCOUNT` com o endereço do programa e `N` com o número de transações: Para comparar dois provedores em vez de medir um, rode os dois streams a partir da mesma máquina e registre qual deles entrega cada transação primeiro. O [geyserbench](https://github.com/hmstudio-labs/geyserbench) público faz isso a partir de um único arquivo de configuração que lista os dois endpoints e informa com que frequência cada um detecta uma transação primeiro. Se você rodar este teste e obtiver números materialmente diferentes dos nossos, nos avise. Descobrir isso é o motivo de o método ser público. ## O que este benchmark não mede? Três coisas ficam deliberadamente fora deste benchmark: - **Confiabilidade do stream.** Este é um benchmark de latência. Ele não mede eventos perdidos, desconexões, tempo de reconexão nem backfill após uma reconexão, então não diz nada a favor ou contra esses aspectos. Se sua aplicação depende de entrega sem gaps, teste isso diretamente. Nossos endpoints mantêm 48 horas de histórico (mais de 400.000 slots), que um cliente ao reconectar pode reproduzir com `from_slot`. - **Inclusão de transações.** Fazer uma transação ser incluída em um bloco é um problema do caminho de escrita, com infraestrutura própria e modos de falha próprios. Nada aqui diz algo sobre isso. - **Leituras de requisição/resposta.** Fazer polling de um método JSON-RPC é um padrão de acesso diferente, com modos de falha diferentes, e nosso [benchmark público de RPC](https://www.alchemy.com/benchmarks) cobre o tráfego de requisições separadamente, com regras próprias publicadas. ## Perguntas frequentes ### Qual é a velocidade do Solana gRPC da Alchemy? Depende de onde você mede, e é por isso que a Alchemy publica distribuições de latência por região em vez de um único número global. A tabela regional acima reporta a ida e volta de rede e a dispersão de entrega p90 e p99, produzidas pela metodologia publicada em uma data declarada. A ida e volta de rede até o endpoint vai de 1,8 ms no Leste dos EUA a 21,9 ms na Europa Ocidental, e as mensagens p99 chegam entre 6,8 e 23,6 ms após a entrega mais rápida, dependendo da região. ### Como a latência do Solana gRPC é medida? Um cliente em cada região abre um stream gRPC com commitment `processed`, observa 20.000 transações em um programa de alto volume e compara o horário de chegada de cada mensagem com o horário em que nosso endpoint a criou. Os resultados são reportados por região como o atraso p90 e p99 acima da entrega mais rápida da execução, junto com a ida e volta mediana de rede do cliente até o endpoint. ### Posso reproduzir os benchmarks de Solana gRPC da Alchemy? Sim. O teste roda a partir do exemplo `latency` do geyserbench, e os comandos exatos estão publicados neste post. Rode em um servidor na região onde você atende seus usuários, com commitment `processed`, e compare seus percentis com a tabela regional. Para comparar dois provedores, o geyserbench também pode rodar os dois endpoints lado a lado a partir da mesma máquina. ### Qual nível de commitment os benchmarks usam? Toda execução se inscreve em `processed`, o primeiro nível de commitment da Solana. Misturar níveis de commitment mediria eventos em pontos diferentes do seu ciclo de vida, o que torna os percentis sem sentido. Sua aplicação em produção pode preferir `confirmed` ou `finalized`; a metodologia mantém o commitment constante para que os números continuem comparáveis entre regiões e execuções. ### Isto é uma comparação com outros provedores? Não. Este post documenta como a Alchemy mede e publica a performance do próprio Solana gRPC. Outros provedores publicam seus próprios benchmarks, e mais metodologia publicada nesta categoria é bom para todos. A seção de reprodução existe para que você mesmo rode a comparação que importa, na sua carga de trabalho. ## Comece a fazer streaming de dados da Solana Nosso [streaming gRPC para Solana](https://www.alchemy.com/solana-grpc) é compatível com Yellowstone, então apontar um cliente existente para ele é uma mudança de URL, não uma reescrita. O preço é $75 por TB, sem mínimo mensal, e a [documentação do Yellowstone gRPC](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview) cobre o guia rápido. Times que constroem na Solana também podem solicitar até $25 mil em créditos pelo [$20M Solana Fund](https://www.alchemy.com/solana-20m-fund). Rode o benchmark primeiro, se quiser. É para isso que ele serve.