Skip to main content
КРИТИЧЕСКИ ВАЖНОЕ ПРЕДУПРЕЖДЕНИЕ: только для производственного ЦОДЭти тесты задержки предназначены только для производственных сред ЦОД. НЕ запускайте их на локальных компьютерах или через обычные домашние интернет-подключения. Пропускной способности локального подключения недостаточно для обработки интенсивных подписок Solana, поэтому результаты будут бессмысленными и не отразят реальную производительность.
ТРЕБОВАНИЕ К СОВМЕСТНОМУ РАЗМЕЩЕНИЮ: развертывайте инфраструктуру рядом с конечной точкой LaserStreamЧтобы получить значимые результаты измерения задержки, вы должны разместить тестовую инфраструктуру в том же регионе, что и выбранная конечная точка LaserStream. Расстояние по сети будет определяющим фактором результатов: при тестировании с другого континента вы измерите сетевую задержку, а не производительность LaserStream.

Общие сведения о задержке в распределенных блокчейн-системах

При работе с сервисами потоковой передачи данных блокчейна измерение задержки усложняется, поскольку в распределенных системах нет универсальных часов. В отличие от традиционных систем, где можно измерить время приема-передачи до одного сервера, блокчейн-сети включают несколько валидаторов, каждый из которых получает и обрабатывает одну и ту же транзакцию в разное время. Основная проблема: в таких блокчейнах, как Solana, нет понятия абсолютного времени. Каждый узел-валидатор в мире получает одну и ту же транзакцию в разное время, а подтверждение зависит от достижения консенсуса определенной долей кластера. Поэтому детерминированное измерение задержки в традиционном понимании невозможно.

Уровни подтверждения и приоритеты задержки

Solana предлагает три уровня подтверждения с разными характеристиками задержки:
  • Processed: самый быстрый, подтверждение одним валидатором (~400 мс)
  • Confirmed: средний, подтверждение квалифицированным большинством (~2–3 секунды)
  • Finalized: самый медленный, полная финализация сетью (~15–30 секунд)
Для приложений, чувствительных к задержке, обычно выбирают уровень подтверждения processed. Во всех тестах этого руководства используется уровень processed, поскольку в большинстве высокочастотных сценариев скорость важнее абсолютной финальности.

Три подхода к измерению задержки

1. Сравнение параллельных потоков gRPC

Самый надежный метод — сравнивает два независимых потока из одного источника данных и определяет, какой из них первым получает идентичные события. Преимущества:
  • Устраняет проблемы синхронизации часов
  • Позволяет сравнивать относительную производительность
  • Обеспечивает наиболее точное сравнение сервисов

2. Сравнение локальной временной метки с created_at

Средняя надежность — измеряет разницу между моментом получения сообщения вашей системой и временной меткой, добавленной в сообщение сервисом LaserStream. Ограничения:
  • Отражает только момент внутреннего создания сообщения в LaserStream
  • Не учитывает задержки на пути к LaserStream
  • Менее точен для измерения реальной сквозной задержки, чем метод 1

3. Анализ временной метки блока (не рекомендуется)

Не рекомендуется — сравнивает локальное время получения с временной меткой блока Solana. Существенные ограничения:
  • Временные метки блоков имеют точность только до секунды
  • Solana создает блоки каждые 400 мс
  • Предоставляет минимум полезной информации

Требования к настройке

Совместное размещение в одном регионе

Чтобы получить значимые результаты измерения задержки, разверните тестовую инфраструктуру в том же ЦОД или регионе, где находится конечная точка LaserStream. Доступные регионы LaserStream:
  • ewr: Нью-Йорк, США (восточное побережье) — https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt: Питтсбург, США (центральная часть) — https://laserstream-mainnet-pitt.helius-rpc.com
  • slc: Солт-Лейк-Сити, США (западное побережье) — https://laserstream-mainnet-slc.helius-rpc.com
  • ams: Амстердам, Европа — https://laserstream-mainnet-ams.helius-rpc.com
  • fra: Франкфурт, Европа — https://laserstream-mainnet-fra.helius-rpc.com
  • tyo: Токио, Азия — https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp: Сингапур, Азия — https://laserstream-mainnet-sgp.helius-rpc.com
Для тестирования в devnet используйте: https://laserstream-devnet-ewr.helius-rpc.com Полные инструкции по настройке и рекомендации по выбору конечной точки см. в документации по gRPC LaserStream.

Настройка среды Rust

Все скрипты измерения используют Rust и Cargo. Базовая настройка:
Создайте файл .env со своими учетными данными:
Получите ключ API Helius в панели управления Helius. LaserStream devnet доступен на всех тарифах. Для доступа к mainnet требуется тариф Business или Professional.

Метод 1: сравнение параллельных потоков

Этот скрипт устанавливает два независимых подключения к разным конечным точкам gRPC и определяет, какое из них первым получает одинаковые сообщения BlockMeta. Такой подход устраняет проблемы синхронизации часов благодаря использованию относительного времени.
Что измеряет этот метод: относительную разницу в производительности двух потоковых сервисов. Разница показывает, какой сервис первым доставляет информацию об одном и том же слоте. Ключевые метрики:
  • Положительная разница: первый сервис (YS) медленнее второго (LS) — LaserStream быстрее
  • Отрицательная разница: первый сервис (YS) быстрее второго (LS) — LaserStream медленнее
  • Среднее/медиана: средняя разница в производительности
  • P95: разница задержки на 95-м процентиле
Запуск теста:
Пример вывода:
В выводе отображаются различия задержки в реальном времени и периодическая статистика. Положительная средняя разница означает, что второй сервис (LaserStream) стабильно доставляет данные быстрее.

Метод 2: анализ временной метки создания

Этот подход сравнивает временную метку created_at, встроенную в сообщения, с локальным системным временем в момент их получения.
Важное ограничение: этот метод измеряет только время между созданием сообщения в LaserStream и его получением. Он не учитывает задержки между событием в блокчейне и обработкой этого события в LaserStream. Запуск теста:
Пример вывода:
Этот метод позволяет оценить сетевую задержку и задержку обработки между LaserStream и вашим приложением, но для комплексного анализа его следует использовать вместе с методом 1.

Рекомендации по тестированию задержки

Основные принципы

  • Совместное размещение: запускайте тесты в том же регионе, что и конечная точка LaserStream, чтобы свести сетевую задержку к минимуму
  • Несколько методов: используйте сравнение параллельных потоков (метод 1) как основную метрику и дополняйте его анализом временных меток
  • Долгосрочный мониторинг: запускайте тесты на длительное время, чтобы охватить разные состояния сети и периоды высокой нагрузки на блокчейн
  • Статистический анализ: чтобы оценить задержку в хвосте распределения, учитывайте прежде всего процентили (P95, P99), а не только средние значения

Интерпретация результатов

  1. Определите базовый уровень: выполняйте тесты не менее 1 часа, чтобы определить базовую производительность в нормальных условиях
  2. Выявляйте закономерности: ищите закономерности во всплесках задержки — связаны ли они с высокой активностью блокчейна или перегрузкой сети?
  3. Сравнивайте процентили: для взаимодействия с пользователем задержка P95 часто важнее средней задержки
  4. Контролируйте стабильность: стабильная производительность часто важнее абсолютного минимума задержки
Помните, что задержка блокчейна по своей природе изменчива из-за требований к достижению сетевого консенсуса. Уделяйте основное внимание относительным различиям в производительности и стабильности, а не абсолютным значениям.