«Почему у меня растет задержка Solana ShredStream?» Причины и решения

В ERPC мы часто получаем запросы от клиентов, использующих поток данных Solana в реальном времени, в которых говорится, что «задержка ShredStream постепенно увеличивается и в конечном итоге прекращается». В этой статье мы подробно объясним основные причины возникновения этой проблемы и предложим конкретные решения для повышения производительности вашего приложения.

В настоящее время ShredStream передает почти все данные в реальном времени без фильтров. Благодаря этому, если вычислительных возможностей клиента недостаточно, данные накапливаются, постепенно увеличивая задержку. Основные причины заключаются в следующем:

Первоначально клиент ShredStream был построен с использованием TypeScript и протокола gRPC. Однако, поскольку фильтры еще не реализованы, использование однопоточной среды, такой как Node.js, быстро достигает пределов обработки, что приводит к постоянному увеличению задержки. Мы обнаружили, что эта проблема не возникает при использовании клиента Rust на том же компьютере, что подтверждает ограничение однопоточной обработки.

В ответ мы разработали решение с использованием технологии NAPI-RS, позволяющее выполнять многопоточную обработку в Rust, сохраняя при этом управление со стороны TypeScript. Это решение, известное как Solana Stream SDK, имеет открытый исходный код и общедоступно:

Потоковые приложения реального времени, использующие Solana ShredStream, обычно адекватно работают на сервере с 4 ядрами и 16 ГБ оперативной памяти. Однако тактовая частота CPU чрезвычайно важна. Более низкие тактовые частоты могут привести к постепенному увеличению задержки. Серверы, предназначенные для максимизации прибыли, часто используют CPU или CPU старого поколения с большим количеством ядер, но с низкой тактовой частотой. Например, CPU AMD EPYC четвертого поколения с множеством ядер (например, 84-ядерные модели) обычно имеют базовую тактовую частоту около 2,2 ГГц и часто не используют турбонаддув эффективно. Поскольку рекомендуемое минимальное требование для валидаторов Solana — 2,8 ГГц, мы настоятельно рекомендуем клиентам также использовать CPU как минимум с этой тактовой частотой. Кроме того, провайдеры VPS обычно используют «overcommitment» — практику разделения одного физического сервера на несколько виртуальных серверов. В среде с чрезмерными нагрузками конкуренция за ресурсы с другими пользователями часто возникает в часы пик, что отрицательно влияет на производительность.

ERPC предоставляет серверы VPS, оснащенные CPU AMD EPYC последнего поколения с тактовой частотой до 4,15 ГГц. Эти серверы обеспечивают производительность, близкую к физическим решениям, и идеально подходят для рабочих нагрузок Solana, требующих потоков данных в реальном времени. Ранее высокочастотные решения VPS были недоступны, что вынуждало пользователей, которым требовалась производительность в реальном времени, выбирать серверы с «Bare Metal». Предложения ERPC VPS устраняют это ограничение.

Решения ERPC VPS оптимизированы для потоковой передачи данных Solana в реальном времени и получили высокую оценку многих HFT-трейдеров и проектов. Эти решения идеально подходят для клиентов, которым необходима высокая производительность без использования ресурсов Bare Metal. Мы рекомендуем вам попробовать наши решения VPS. Чтобы получить бесплатные пробные версии или подробные консультации, посетите официальный сайт Validators DAO Discord: