“Por que meu Solana ShredStream Latency continua aumentando” Causas e soluções

Em ERPC, recebemos frequentemente perguntas de clientes usando o fluxo de dados em tempo real da Solana, afirmando que "ShredStream a latência aumenta gradualmente e eventualmente pára."

Neste artigo, vamos explicar claramente as principais razões pelas quais esta questão ocorre e oferecer soluções concretas para melhorar o desempenho da sua aplicação.

Atualmente, ShredStream transmite quase todos os dados em tempo real sem filtros. Devido a isso, se as capacidades de processamento do cliente forem insuficientes, os dados se acumulam, aumentando gradualmente a latência.

As principais causas são as seguintes:

Inicialmente, o ShredStream o cliente foi construído usando TypeScript e o gRPC protocolo. No entanto, uma vez que os filtros ainda não são implementados, usando um ambiente de fio único como Node.js rapidamente atinge os limites de processamento, fazendo com que a latência aumente continuamente.

Identificamos que esse problema não ocorre quando se utiliza um cliente Rust na mesma máquina, confirmando assim a limitação do processamento de fio único.

Em resposta, desenvolvemos uma solução utilizando N-API- tecnologia RS, permitindo processamento multi-threaded em Rust, mantendo o controle de TypeScript. Esta solução, conhecida como Solana Stream SDK, é de código aberto e está disponível publicamente:

Se você estiver usando Node.js ou TypeScript, recomendamos muito usar este SDK. Para o máximo desempenho, considere usar uma linguagem nativa multi-threaded como Rust.

Aplicações de fluxo em tempo real utilizando Solana ShredStream normalmente operar adequadamente em um servidor com 4 núcleos e 16GB de RAM. No entanto, a velocidade do clock da CPU é extremamente importante. Velocidades de clock mais baixas podem levar a um aumento gradual da latência.

Servidores destinados a maximizar o lucro muitas vezes usam CPUs de geração mais antiga ou CPUs com muitos núcleos, mas baixa velocidade de clock. Por exemplo, CPUs AMD EPYC de quarta geração com muitos núcleos (como os modelos de 84 núcleos) normalmente têm um relógio base de cerca de 2,2GHz e muitas vezes não utilizam efetivamente turbo impulso. Como o requisito mínimo recomendado para os validadores da Solana é de 2.8GHz, aconselhamos fortemente os clientes também a adotar CPUs com pelo menos esta velocidade de clock.

Além disso, VPS provedores comumente usam "overcommitment", uma prática de dividir um servidor físico em vários servidores virtuais. Em um ambiente supercomprometido, a competição de recursos com outros usuários ocorre frequentemente durante os tempos de pico, impactando negativamente o desempenho.

ERPC fornece VPS servidores equipados com as CPUs AMD EPYC de última geração com velocidades de clock até 4,15GHz. Esses servidores oferecem desempenho próximo às soluções de Bare-Metal, perfeitamente adequados para cargas de trabalho Solana que exigem fluxos de dados em tempo real.

Anteriormente em High Clock VPS soluções não estavam disponíveis, forçando os usuários a optarem por servidores desnudos em tempo real. da ERPC VPS As ofertas resolvem esta limitação.

ERPC's VPS As soluções são otimizadas para a transmissão de dados em tempo real da Solana e altamente elogiadas por muitos traders e projetos de alta frequência.

Estas soluções são ideais para clientes que necessitam de alto desempenho sem exigir os recursos de um servidor de metal.

Encorajamo-lo a experimentar o nosso VPS soluções.

Para testes gratuitos ou consultas detalhadas, visite Validators DAOé oficial Discord:

ERPC continua empenhada em continuar pesquisa e desenvolvimento para atender suas necessidades em evolução e apoiar melhor desempenho.

Obrigado pelo seu apoio contínuo.